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Februári számunk fő témája 

a biztonságtechnika. 

Ha az ember Linuxot használ, 

az persze önmagában is 
viszonylag nagy biztonságot 
jelent a mai , vírusterhes" idők- 
ben, ugyanakkor két dolgot 

nem szabad elfelejtenünk. 

Egyrészt teljes biztonság nem léte- 
zik, tehát azt a linuxos rendszergaz- 
dát, aki elhanyagolja a rendszerét, 
előbb vagy utóbb de biztosan megle- 
petés fogja érni. Hogy miként marad- 
hatunk naprakészek a biztonsági fÍris- 
sítésekkel, azt Jeremy Turner cikkéből 
tudhatjuk meg. 

A másik lényeges szempont, hogy 

a Linux használói között számos 
olyan ember akad, aki nem csupán 

a saját gépének biztonságáért felel, 
hanem mások testi, lelki és digitális 
épségét is a szívén viseli. Egyesek 
puszta felebaráti szeretetből teszik 
ezt, míg mások azért, mert kifejezet- 
ten ezért fizetik őket. 

A rendszer belső biztonságát nyilván 
nagyban növeli, ha a különböző ob- 
jektumokkal, és a rajtuk végezhető 
műveletekkel kapcsolatos jogosultsá- 
gokat a felhasználók szerepe, munka- 
köre alapján osztjuk ki. Mivel a UNIX 
hagyományos jogosultsági rendszeré- 
vel bizonyos dolgokat nehéz, vagy 
egyenesen lehetetlen megoldani, az 
NSA elkészített a Linuxhoz egy speci- 
ális biztonságtechnikai kiegészítést 
(Security Enhanced Linux), amely ké- 
pes a szerepek és jogosultságok össze- 
rendelésére. Egy ilyen megerősített 
rendszer hálózati funkcióit tekinti át 
James Morris cikke. 

Egy olyan világban, ahol a posta 
szerepét egyre inkább átveszi az elekt- 


ronikus levél, sőt a kormányhivatalok 
is törekednek az elektronikus ügyinté- 
zésre, nyilván egyre komolyabb ve- 
szélyt jelent az üzenetek lehallgatása, 
vagy rosszindulatú módosítása. Roy 
Hobler erről a témáról, vagyis az elekt- 
ronikus levelek gyors és egyszerű tit- 
kosításáról ír. 

A biztonságtechnika egyik alapsza- 
bálya, hogy soha nem szabad alábe- 
csülni a triviális hibalehetőségeket. 
Lehet bármilyen jól szervezett egy 
gép belső biztonsági rendszere, lehet- 
nek akármilyen körmönfont módon 
titkosítva a hálózati kapcsolatai, bárki 
hozzáférhet a teljes adattartalmához, 
ha egyszerűen ellopja. Mike Petullo 
cikkéből megtudhatjuk, miként 
titkosítható Linux alatt akár a gyökér 
fájlrendszer is. 

lermészetesen folytatódik néhány 
sorozat is. 

Beszédes Balázs a felhasználók 
jószándékú megfigyelésének immár 
egészen gyakorlati módszereit tárgyal- 
ja, Auth Gábor a FreeBSD, Komáromi 
Zoltán pedig a PHP 5 bemutatásával 
haladt tovább. Illés Viktor ugyanakkor 
egy új, a Samba 3 képességeit tárgyaló 
sorozatba kezdett bele. Ez a rendszer 
azért különösen érdekes, mert egye- 
sek a Windows 2003 Server ,utódát" 
látják benne. Garzó András a hálóza- 
tokról szóló sorozat immár 14. részé- 
ben a forgalomirányítás rejtelmeit 
taglalja, Dudás Ágnes pedig arról ír, 
hogy szerzői jogi szempontból mi 

a helyzet az olyan alkotásokkal, ame- 
lyek munka- vagy szolgálati viszony 
keretében keletkeztek. 


Jó szórakozást kíván 
a Linuxvilág stábja! 
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Környezetvédelem csak eredetiben 
Kibővült az OKI kellékanyagok vissza- 
vételére irányuló környezetvédelmi 
programja. A cég július 4-től már 
visszaveszi a használt tintapatronokat, 
ezt a lehetőséget most 

a lézernyomtatók toner- 
jeire és ftényhengereire is 
kiterjesztették. Sőt, nem 
egyszerű visszavételről, hanem - igaz, 
jelképesnek mondható áron - vissza- 
vásárlásról van szó, a kedvezményt új, 
eredeti OKI kellékanyag vásárlásakor 
lehet érvényesíteni. Sajnos az OKI ma- 
gyar webhelyén található tájékoztatás 
meglehetősen szűkös (idézet: , Ha 
igénybe kívánja venni ezt a lehetősé- 
get, látogasson el a részletekért saját 
országának webhelyére."), ezért a fel- 
használók elsősorban a kereskedők- 
höz fordulhatnak. 

2 www.okihu.hu 


Kipróbálható az Nvu 

Múlt év decemberének elején megje- 
lent az Nvuu weblapfejlesztő alkalmazás 
első próbaváltozata, amelyet kicsivel 
több mint egy hónappal később újabb 
próbakiadás követett. 
A Linux és Windows alá 
készülő, utóbbi alatt 

a jól ismert FrontPage 

és Dreamweaver programokat versenyre 
hívó Nuu segítségével a HIML nyelv 
ismerete nélkül is bárki készíthet web- 
oldalakat és gondozhat webhelyeket. 
Az Nuu a Mozillában is megtalálható 
Gecko megjelenő motorra épül, tőle 
örökli az XML, a CSS és a JavaScript tá- 
mogatást. A többek közt FIP alapú 
webhelykezelővel, CSS szerkesztővel, 
testreszabható eszköztárakkal, űrlap- 
szerkesztővel, kódellenőrzővel és 

— tisztítóval, helyesírás-ellenőrzővel 
rendelkező programra minden hasonló 
területen dolgozónak érdemes lehet 
egy pillantást vetnie. 

2 www.nvu.com 


NVU 


Betörők, mosolyogni! 

Az olasz CFD Elettronica beágyazott 
Linuxra épülő otthoni riasztórendszert 
mutatott be. A Plenitude Premium rend- 
szer többféle egységet, például hagyo- 
mányos érzékelőszemeket is magába 
foglal, ám a legérdekesebbek ezek kö- 
zül az infravörös érzékelőkkel irányí- 
tott vezeték nélküli kamerák. Ezek, ha 
mozgást észlelnek, két fekete-fehér fo- 
tót készítenek és továbbítanak a köz- 
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ponti egység felé, amely viszont képes 
arra, hogy a képeket GPRS, Bluetooth 
vagy Wi-Fi összeköttetésen keresztül 
mobiltelefonra vagy egyéb eszközre 
küldje tovább. A központi egység saját 
kijelzővel is rendelkezik, ezen igény 
szerinti mozgóképes felügyeletre vagy 
a korábbi eseményekhez tartozó képek 
visszanézésére nyílik lehetőség. A köz- 
pont egy 400 MHz-es Intel XScale pro- 
cesszort, 64-128 MB memóriát és 32- 
64 MB Flash memóriát tartalmazó egy- 
lapkás számítógépet rejt, operációs 
rendszere a 2.4-es Linux rendszermag- 
ra épül. Az üzletekbe várhatóan csak 
nyáron kerülő rendszer ára 4500 euró 
körül fog alakulni. 

2 www.cfd.it 


Égy gép előtt a család 

Az Open Sense Solutions Groovix néven 
olyan számítógépeket mutatott be, 
amelyek egyszerre akár három fel- 
használónak is 


ú XX képesek teljes 
L.-h értékű munka- 
; fr környezetet 
e jeleltáb biztosítani. 
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Hasonló meg- 
oldások már eddig is léteztek, ezek 
például egy kiegészítő kártya révén 
oldották meg a második felhasználó 
csatlakoztatását, ám a Groovix eseté- 
ben csak külön VGA- és - szükség 
esetén — hangkártyákra van szükség, 

a megosztás többi részét szoftver- 
könyvtárakra bízták. A Groovix fontos 
jellemzője, hogy a saját billentyűzet, 
egér és kijelző mellett mindegyik fel- 
használó 3D gyorsított megjelenítést 
és saját hangkártyát kap. A Groovix gé- 
pek hardveres oldalról ugyan minősé- 
gi, de teljesen hétköznapi összeállítá- 
sok, különlegességük a Simultaneous 
Local Independent Multi-User (SLIM, 
egyidejű, helyi, független többfelhasználós) 
megoldásban rejlik — ezek a Debian 
Linuxra készített könyvtárak gondos- 
kodnak a felhasználók elkülönítéséről. 
Mivel a megosztás szoftver alapú, a fel- 
használóknak nem javasolják, hogy 
más operációs rendszert telepítsenek 

a gépre, illetve, ha ezt mégis megteszik, 
akkor le kell mondaniuk a többfelhasz- 
nálós működésről. Az egyetlen felhasz- 
nálót kiszolgáló gépet a cég 599, a ket- 
tős használatra tervezettet 799, míg 

az erőforrásokat három fő között meg- 
osztót 999 dollárért kínálja. 

2 www.opensensesolutions.com 


phpBeans 

A Simian Systems Inc. bejelentette 

a phpBeans előírásgyűjteményt, melyet 
követve, alkalmazva a fejlesztők való- 
ban nagyvállalati szintű PHP-s alkalma- 
zásokat készíthetnek - a cég állítása 
szerint erre eddig nem volt lehetőség. 
A phpBeans olyan módszert ír körül, 
melynek segítségével a különböző 
gépeken létező objektumok egymással 
átlátszó módon, távoli eljáráshívással 
léphetnek kapcsolatba, így a különféle 
programszintek egymástól könnyedén 
elkülöníthetők. A tervezet része — bár 

a fő szerepet a szabványos távoli eljá- 
ráshívási módszerek, és nem a tényle- 
ges programok játsszák — a phpBeans 
Object Server, egy objektumkonténer 
kiszolgáló, mely hitelesített tranzakciók 
lebonyolítását teszi lehetővé az általa 
tárolt objektumok és a csatlakozó ügy- 
felek között; a phpBeans Client API, mely 
egy nemcsak PHP, hanem más nyelvek 
alá is elérhető könyvtár, segítségével 

a programozók kéréseket indíthatnak 

a távoli phpBeans Object kiszolgálók felé; 
valamint a phpBeans protokoll, mely 
egyszerű, gyors és hatékony adatátvite- 
li rétegként segíti a tranzakciók lebo- 
nyolítását. A phpBeans objektumkiszol- 
gáló GNU GPL és kereskedelmi szerző- 
déssel, míg az ügyfél API GNU LGPL 
szerződéssel érhető el, így mindegyik 
felhasználó megtalálhatja a számára 
leginkább megfelelő konstrukciót. 

2 www.phpbeans.com 


On vett már IBM üzletágat? 

A vezető kínai PC-gyártó, a Lenovo 
Group Limited felvásárolta az IBM PC- 
gyártó üzletágát. A körülbelül 1,/5 


FEnOoOvo xs 
milliárd dolláros üzletkötés nyomán 
a Lenovo a világ harmadik legnagyobb 
PC-gyártója lesz, éves forgalma a becs- 
lések szerint 12 milliárd dollár körül fog 
mozogni. A megegyezés szerint a két 
cég között nemcsak egyszerű adásvétel 
történt, hanem hosszú távú értékesítési, 
szolgáltatási és pénzügyi szövetséget 
hoznak létre. Az egyesült vállalat a vi- 
lág 160 országában lesz jelen, Kínában 
a Lenovo, azon kívül pedig az IBM által 
korábban bevezetett márkanevek révén 
lesz ismert. A gyártás a Lenovo, a szol- 
gáltatások biztosítása pedig az utóbbi 
időben hangsúlyosan a szolgáltatások 
felé forduló IBM feladata lesz. 
2 www.lenovogrp.com 


sokcsatornás MP3 

A Fraunhofer Intézet oldalára felkerül- 
tek az első, a térbeli hangzást kínáló 
mp3 formátummal kapcsolatos anya- 
gok. Az egyelőre csak Windows és Mac 





OS X alá elérhető, ingyenesen letölt- 
hető próbacsomagok fejlesztői készlet- 
ből, surround dekóderből, kódolóból, 
lejátszóprogramból állnak, illetve 

a windowsos változat Winamp beépülő 
modult is tartalmaz. Az új formátum 
kipróbálását néhány szintén szabadon 
letölthető dallal is segítik, az intézet 
ígérete szerint a mintakészlet hamaro- 
san bővülni fog. Az új mp3 formátum 
5-1 csatorna hangjának közvetítésére 
alkalmas, az újfajta kódolású fájlok 

a csak a régebbi, sztereó változat keze- 
lésére képes eszközökön is lejátszha- 
tók, miközben méretük nem sokkal 
haladja meg a csupán két csatornát tá- 
roló állományokét. A mintaprogramok 
futtatásához legalább 1 GHz órajelű 
Pentium III vagy azzal egyenértékű 
processzorral, 128 MB memóriával és 
5.1-es hangkártyával felszerelt gépre 
és a DirectX 9.0 vagy újabb változatára 
van szükség. 

2 wwwiis.fraunhofer.de/amm/ 
download/mp3surround/index.html 


Megújult LinuxSecurity.com 
Megújult, kibővült a linuxos és nyílt 
forrású programokkal kapcsolatos biz- 
tonsági kérdésekkel foglalkozó 


Linux 
LinuxSecurity.com webhely. A még 
1996-ban indított, a Guardian Digital 
munkatársai által gondozott hely az 
elmúlt évek során az informatikai 
szakemberek és a nyílt közösség tagjai 
körében egyaránt kedvelt információ- 
forrássá vált, oldalain a világ minden 
tájáról származó írások, útmutatók, le- 
írások jelennek meg, de a biztonsági 
frissítések beszerzésében, továbbá fó- 
rumok formájában az eszmecseréhez 
is segítséget kínál a látogatóknak. 

2 www .inuxsecurity.com 
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Médiatitkár a zsebben 

Elvileg már ebben a hónapban kapható 
lesz az Archos Linux alapú személyi 
videófelvevő és -lejátszó készüléke. 

A Pocket Media Assistant 400, röviden 
PMA400 jelzésű 
készülék 30 GB 
kapacitású merev- 
lemezzel, LUISB, 
Wi-Fi és infíravö- 
rös csatolóval, 
320x240 képpont felbontású, 3,5"-os 
IFT kijelzővel és TV-kimenettel rendel- 
kezik, operációs környezete Otopia ala- 
pú, így a multimédiás szolgáltatásokon 
túl — kiegészítő billentyűzettel — szemé- 
lyi adatkezelésre és egyéb alkalmazá- 
sok futtatására is alkalmas. A kismére- 
tű, tudásához képest meglepően 
könnyű, 280 grammos készülék az 
MPEG-4 és az mp3 formátumot támo- 
gatja, előbbi révén közel DVD-minősé- 
gű mozgóképek tárolására és lejátszá- 
sára képes. Ára 800 euró. 

2 www.archos.com 


Zöld út a magyar UMTS hálózatoknak 
A Nemzeti Hírközlési Hatóság kihirdette 
a hosszas késlekedés után tavaly nyá- 
ron kiírt, harmadik generációs UMTS 
mobitelefon-hálózatok kiépítésére vo- 
natkozó pályázat eredményét. A Ha- 
tóság döntése szerint mindhárom 
Magyarországon már jelen lévő mobil- 
szolgáltató — Pannon GSM Távközlési 
Rt., T-Mobile Magyarország Rt., Vodafone 
Magyarország — jogot nyert a bővítésre, 
míg a negyedik blokkot, amellyel egy 
újabb szereplő piacra lépését szerették 
volna ösztönözni, egyelőre senkinek 
nem ítélték oda. A harmadik generáci- 
ós hálózatok beindítása 2006-ban vár- 
ható, segítségükkel a mostaninál gyor- 
sabb adatátvitelre, jobb hangminőségű 
telefonálásra — amit talán jobb lesz, 

ha a továbbiakban hangtelefonálásnak 
hívunk -—, videotelefonálásra, multi- 
médiás szolgáltatások igénybe vételé- 
re lesz lehetőségünk. A három cég 

a jogokért több évre elosztva összesen 
több mint 50 milliárd forintot fizet 

be az államkasszába. 

2 www.nhh.hu 


Medgyesi Zoltán 
(mz€rettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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Fal, amely összeköt - az FSN.hu tégla projektje 


Az FSN.hu alapvető célja, hogy megfelelő infrastrukturális hátteret biztosítson 
a szabad szoftverekkel foglalkozó emberek és szervezetek számára. A hardvernek 
azonban megvan az a rossz szokása, hogy viszonylag gyorsan elavul... 


éa gy nemrég az Összefogás a szabad szoftverek elterjeszté- 
li séért alapítvány (Free Software Network; ESN) is a gép- 
park lecserélése mellett döntött. Nonprofit szervezet 
lévén ehhez a szabad szoftverek iránt elkötelezett emberek 
segítségét kérte. Papíron megterveztek egy olyan rendszert, 
amely képes kiszolgálni a magyar felhasználókat, az árát 
1000 egyenlő részre osztották, és ezeket a , téglákat" igyekez- 
nek ,eladni". Az interjú idején a , téglaszámláló" 231-en 
állt... (2 http:/www.fsn.hu/?f—brickézsetlang— hu). 
A projektről és az FSN céljairól Nagy Attilát, az alapítvány 
elnökét kérdeztük. 


Tulajdonképpen miért kell segíteni a szabad szoftverek elterje- 
dését? Az ember azt gondolná, hogy ha valamire ingyen van, 
azt az emberek maguktól is megtalálják. Szóval eredetileg 
honnan jött az ötlet, és pontosan kik állnak az FSN mögött? 
A szabad szoftverek mögött egy igen erős meggyőződés, 
ideológia áll. A szabad szoftverek szerelmeseinek célja, hogy 
azt a tudást, amelyeket ezek a programok képviselnek, min- 
denki korlátok nélkül felhasználhassa a saját céljai elérésére. 
Mivel ezeket leggyakrabban non profit módon fejlesztik, 

a fizikai és az ismeretterjesztés a közösség feladata marad. 
Az ESN mögött (Free Software Network, amelyet az Összefogás 
a szabad szoftverek elterjesztéséért alapítvány az internetes 
megjelenésénél használ) hat, szabad szoftvereket régóta sze- 
rető, használó ember áll: Nagy Attila (bra), elnök, Riskó Gergely 
(errge), titkár, Beregszászi Alex (alex), Micskó Gábor (trey), 
Pásztor György (gyu), és Petrikovics Balázs (gaab). 

Az alapítványunk elsősorban nem a megtalálásban segít, 
hanem az információhoz való gyors hozzáférésben, amely- 
nek két prominens képviselője a hup.hu portál és az 
ftp.fsn.hu fájlszerver. 


Miért jobb, ha Magyarországon is van egy olyan kiszolgáló, 
amin megtalálhatjuk a szabad szoftverek legfrissebb változa- 
tát? Miért nem használjuk egyszer?en az olyan nemzetközi 
helyeket, mint a sourceforge.net, vagy a freshmeat.org? 

A Sourceforge és a Freshmeat funkciója némileg eltér az FSN 
által biztosított szolgáltatásokéitól. Az első egy fejlesztői 
webhely, míg a második a szabad szoftverek legújabb verzi- 
óira hívja fel a figyelmet. Annak, hogy Magyarországon is 
elérhetőek ezek a szoftverek, rengeteg előnye van. Egyrészt 
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szinte mindenki által ugyanolyan gyorsan hozzáférhetőek, 
hiszen nem korlátozza a letöltést az egyes internet-szolgál- 
tatók nemzetközi sávszélessége, illetve a tükrözéseken kívül 
saját tartalmat is igyekszünk biztosítani (beleértve a hazai 
projektek megjelenését is). 


Hétköznapi igényekhez mérten igen impozáns teljesítménnyel 
rendelkező gépet akartok beszerezni. Nemzetközi viszonylat- 
ban, vagyis a többi szabad szoftverekkel kapcsolatos helyhez 
képest mennyire számít nagynak ez a rendszer? 

Az ESN forgalma a szerverek elhelyezését biztosító Axelero 
Rt-nél is meghatározó, azt külön monitorozzák és egyes 
esetekben szabályozzák. Ez azt hiszem jól mutatja, hogy 

a forgalmunk mind hazai, mind nemzetközi viszonylatban 
is jelentős. Mindezt úgy érjük el, hogy a szervereink nagy 
hiszem ma már meglehetősen kicsinek számít. Ezen szeret- 
nénk javítani azzal, hogy a terhelésnek megfelelően bővít- 
jük az erőforrásokat. Az új gép nemzetközi mércével mérve 
közepesnek mondható. Külföldön általában több gépből ál- 
ló szerverfarmot használnak, nem ritka, hogy 8-10 IB-os 
háttértárral és több gigabites hálózati kapcsolattal. 


2005. január 3-án az 1000-ből még csak 196 tégla jött össze, 
az akció pedig február végéig tart. Bíztok benne, hogy meg- 
lesz a szükséges összeg? Vannak kiegészítő források? 

Szinte minden lehetőségünket felhasználtuk már. Logókat 
kaptunk a közösségtől, amelyeket kitehettünk pár szakmai 
és nem szakmai oldalra is. A projekt szerepelt a Fix TV mű- 
során és a Fiksz rádióban is. Sokan felajánlották, hogy segíte- 
nek a kedvezményes beszerzésben. Sajnos azonban az esz- 
közök beszerzéséhez pénzre van szükség, amely - egyelőre 
úgy tűnik — nem fog összejönni az eredeti határidőre, amit 
ennek megfelelően szeretnénk legalább egy hónappal kitol- 
ni. Valószínűleg így sem fog összejönni a teljes összeg, de ta- 
lán egy picivel közelebb kerülünk hozzá. Kiegészítő források 
sajnos nincsenek. A gyártók és forgalmazók néhány eszközt 
tudnának olcsóbban adni, de csak ha valamennyi pénz 
(legalább 60-7090) összejön. Az adománygyűjtés után felke- 
ressük őket, és meglátjuk, ki mit tud ennyiért adni. 
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Ni újság a rendszermag fejlesztése körül? 





Markus Lidelt nevezték ki az /ntelligent 
Input/Output (120) karbantartójának. Az /20 
Special Interest Group által tervezett /20 olyan al- 
katrész szabvány, amely lehetővé teszi, hogy a kI- 
bemenet terhelés alól felszabadítsuk a CPU-t és 
ezzel megnöveljük az alkatrész [I/O teljesítményét, 
miközben a futó rendszerre gyakorolt hatását Is 
csökkentjük. Markus viszonylag új ember a Linux 
rendszermag fejlesztésben, 2004 márciusában 
jelent meg először rendszermag változás- 
naplóiban néhány kisebb /20 folttal 

a 2.6.1-es rendszermaghoz. 

Itt Is, mint annyi más projekt- 
nél ez idő tájt de facto Alan 
Cox volt karbantartó és 
meglehetősen sok foltot 
fogadott el Markustól 

a következő néhány hó- 
napban. 2004 júliusára 

a 2.6.3-as megjelenésekor 
viszont már Markus fogadta 

el az /20 csomagokat más 
fejlesztőktől. 2004 augusztu- 
sában, Warren logami Markust 
jelölte hivatalos karbantartónak, 
így Andrew Morton jóváhagyása után, 

Markus 2004 szeptemberében frissítette a kar- 
bantartók fájlját és bejegyezte magát /20 karban- 
tartóként. Nem sokkal ezt követően kezdeményez- 
te az /20 kód újraírását/újraszervezését amelyet 
Andrew új, stabil rendszermagokban alkalmazható 
nagyobb változtatásokról szóló szabadabb rend- 
szabályaival összhangban a 2.6.9-rc2 rendszer- 
magba be Is vettek. 


A rendszermagfejlesztés gyakran teli van viták- 

kal és problémákkal. Mostanában a Philips web- 
kamerákat támogató pwc meghajtó robbantott 

ki vitát a meghajtó karbantartójaként Ismert 
Nemosoft Unv, és a Linux Journal rovatvezető és 
kernelkapítány Greg Kroah-Hartman között. A kü- 
lönféle alkatrészek támogatása érdekében a rend- 
szermag szabályaival ellentétes módon régóta léte- 
zett egy hurok amellyel bináris modulokat lehetett 
a rendszermagba csatolni. Míg Greg sürgette az el- 
távolítását, Nemosoft pedig arra kérte Linus-t, 
hogy az egész meghajtót távolítsa el a rendszer- 
magból. Most, hogy a meghajtó már a GPL oltalma 
alá esik, a szerzőnek nincs Jogi alapja ilyesmit kö- 
vetelni, Linus Torvalds azonban úgy érezte teljesí- 
tenie kell a szerző kívánságát, különösen figyelem- 
be véve, hogy a kérdéses kód karbantartó nélkül 
marad. Mint kiderült, ez nem volt éppen népszerű 
döntés néhány ember, például Alan Cox, szemé- 
ben, akik kicsit konzervatívabban állnak hozzá 

a szabadalmi kérdésekhez. A Nemosoft kiadta 
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a kódot, tehát nem veheti csak úgy vissza. Állítása 
igazolására Alan kijelentette, hogy ő is megkérhet- 
né Linus-t, hogy távolítsák el az évek során össze- 
gyűlt összes Alan munkát, ami lényegében a rend- 
szermag elég tetemes részét tenné ki és tönkre- 
tenné a teljes projektet. Alan álláspontja szerint 
ilyen esetekben egyszerűen nincs értelme teljesíte- 
ni a szerzők kérését. Hosszas vita után, Luc 
Saillard visszafejtette a kérdéses bináris modult 
és elküldte a pwc meghajtó új, kérdéses 
hurok nélküli változatát. 


David Engebretsen úgy döntött 
tovább már nem vállalja 
a PowerPC karbantartói fel- 
adatalt, Így helyét Pau/ 
Mackerras és Anton 
Blanchard foglalta el, akik 
Benjamin Herrenschmidt, 
TIom Rini és még sok más 
szerzővel együtt rengeteg 
PPC foltot küldtek az évek so- 
rán. David az IBM-nél munkája 
részeként tartotta karban a PPC 
változatot és az eredeti PPC64 Linux 
változat átírását végző csapatot vezette. 


Jeff Garzik elkészítette a biktool eszközt, az eddig 
használt hdparm kezelhetőbb általánosabb változa- 
tát . A hdparm-hoz hasonlóan, a biktool is pusztulást 
hozhat a merevlemezünkre ha helytelenül használ- 
juk. Akárcsak a hdparm, a biktool Is eléggé /DE- 
centrikus, bár Jeff a SCSI, 120 és RAID támogatá- 
son is dolgozik. A hdparm IDE-centrikussága való- 
színűleg abból ered, hogy annak idején Mark Lora, 
az eredeti /DE alrendszer karbantartója készítette. 

A hdparm programhoz hasonló módon a bliktool pa- 
rancssoros felületen keresztül teszi elérhetővé 

a merevlemezünk apró részleteit, és segítségével 

a felhasználó finom módosításokat végezhet műkö- 
dés terén ami jelentős sebességnövekedést Is okoz- 
hat. A biktool parancssora által használt pontos csa- 
tolófelület még képlékeny; kiváltképp miután Alan 
Cox úgy érzi, hogy amennyiben egy új eszközt fej- 
lesztünk ki, annak javítania kell a hdparm eszközben 
felmerült hibákat különös tekintettel a parancssoros 
felületre. Jeff úgy tűnik kapható a különféle alterna- 
tívákra, így a végső eszköz valószínűleg többféle 
módszert Is nyújt majd a felhasználóknak céljaik el- 
éréséhez. A lényeg, hogy Jeff kezdeményezése tá- 
mogatásra talált a kernelfejlesztők közt, és így a né- 
pek végül helyére pofozzák. 


Zack Brown 
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Új termékek 


RILinuxPro 2.1 


A FSMLabs megjelentette az 
RILinuxPro kettős rendszermagú, 
valós idejű operációs rendszer 2.1- 
es változatát. Az RILinuxPro 2.1 új- 
donsága többek közt a társ operá- 
ciós rendszer továbbfejlesztett 
névtér-particionálása, amely a ma- 
gasabb fokú megbízhatóságot és 
a hibakeresés és -elhárítás meg- 
könnyítését szolgálja; a Jobb VME- 
támogatás az Ipari és a légi, vala- 
mint védelmi alkalmazások számá- 
ra; az új processzortípusok kiter- 
jesztett támogatása; valamint a kI- 
bővített POSIX APl-k, amelyek 

a kód hordozását, a szabványos fo- 
lyamatok, szálak és készülékek kö- 
zötti adatcserét segítik elő. A be- 
ágyazott, több géptípust Is felölelő 
fejlesztésekhez készült R/LinuxPro 
Development Kíit az RILinuxPro 2.1 
kiadásával szintén frissült, újdonsá- 
ga a Visual SlickEdit IDE. 
www.fsmlabs.com 


ACCPAC Advantage Serles 
5.3-as változat 

Az ACCPAC Advantage Series 
számlázórendszer 5.3-as változata 
új tranzakcióelemző szolgáltatással 
bővült, segítségével a felhasználók 
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olyan kódokkal láthatják el a tranz- 
akciókat, amelyek a tranzakciók tel- 
jes ideje alatt változatlanul marad- 
nak. A címkék alapján mód nyílik 
jelentések készítésére, valamint 

a hagyományos pénzügyi Jjelenté- 
seken túl részletesebb elemzése- 
ket is lehet készíteni. Az 5.3-as ki- 
adásba tucatnyi egyéb bővítés is 
került, többek közt átdolgozták 

a számlázó modulokkal kapcsola- 
tos biztonsági szolgáltatásokat; az 
ACCPAC webalkalmazáson keresz- 
tül lehetővé vált a makrók létreho- 
zása és futtatása; a beépített, az 
új rendelési modullal együttműkö- 
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dő készletkezelő révén pedig fel- 
gyorsult a feldolgozás és a szállítá- 
sok teljesítése. 

www.accpac.com 


SuSE Linux Professional 9.2 
A SuSE Linux Professional 9.2 32 
bites x86 processzorokra és AMD 
és Intel 64 bites lapkákra érhető el. 
A SuSE 9.2 támogatja a Bluetooth 
vezeték nélküli kapcsolatokat; 

a Bluetooth-képes készülékeket 





a YaST közreműködésével önmű- 
ködően Ismeri fel. A Bluetooth- 
kezelő program segítségével a fel- 
használók könnyedén csatlakozhat- 
nak a WLAN-okhoz és az egyéb 
hálózatokhoz, illetve gond nélkül 
mozoghatnak közöttük. A SuSE 
9.2-nek része a KDE 3.3 és 

a GNOME 2.6 asztali környezet; az 
OpenOffice.org 1.1.3; az Evolution 
2.0; a Ihe GIMP 2.0; az Inkscape 
vektorgrafikai és az Nvu weblapké- 
szítő alkalmazás. Szintén a terjesz- 
tés része, ám zárt alkalmazás 

a lextMaker és a PlanMaker, az 
SEP biztonsági mentő program, 
valamint a MainActor 5 videoszer- 
kesztő bemutató változata. 
www.suse.com/lus 


Yellow Dog Linux 4.0 

A Terra Soft Solutions bejelentette 
a Yellow Dog Linux (YDL) 4.0 válto- 
zatát, mely 32 bites támogatást 
nyújt az USB-G3, G4 és G5 Power 
Mac gépekhez, továbbá a Free- 
scale Board Support Package ré- 
vén a Genesi Pegasos II AIX alap- 
lapok támogatása Is megoldódott. 








A YDL 4.0 Fedora Core 2 alapú, 
KDE 3.3 és GNOME 2.6.0 környe- 
zetet tartalmaz; telepítője és maga 
a munkakörnyezet egyaránt meg- 
újult megjelenést kapott. A YDL 
4.0 terjesztésbe beépített alkalma- 
zások között például az OpenŐffice 
1.1.1, a Rhythmbox 0.8.3 és 

a Mozilla 1.7 található meg, míg 

a fejlesztők munkáját a 32 bites, 
2.6.8-as rendszermagra épült glibc 
2.3.3 és GCC 3.3.3 segíti. Az YDL 
4.0 fontos újdonsága a külső esz- 
közök kiterjesztett USB-támogatása 
és a beépített FireWire-támogatás; 
utóbbival — kézi beállításokkal — 
akár a FireWire alapú rendszerindí- 
tás Is megoldható. A PowerBook 
és a G4/G5 Power Mac gépeken 

a kétmonitoros használat is lehető- 
vé vált. A vezeték nélküli kapcsola- 
tok felépítése Netgear VVG511 54 
Mb PCMCIA kártyán keresztül le- 
hetséges, a D-Link és Linksys USB- 
s kártyák támogatásának megvaló- 
sítását a közeljövőre tervezik. 
www.terrasoftsolutions.com 


Sugar Sales 2.0 


A LAMP alaprendszerre épülő 
Sugar Sales és Sugar Sales 
Professional 2.0 nyílt forrású fo- 
gyasztói kapcsolatkezelő (CRM) 
alkalmazások a SugarCRM, Inc. 
újdonságai. A Sugar Sales 
Professional 2.0 új szolgáltatása 
az ajánlatkészítő és az árlista mo- 
dul, melynek segítségével az érté- 
kesítő hozzáférhet a termékárak- 
hoz, Illetve módosíthatja azokat, 
továbbá testreszabott ajánlatokat 
készíthet és menthet ki PDF for- 
mátumba. Mindkét CAM alkalma- 
zás utasításkövető képességekkel 
is rendelkezik, amelyek révén 

a felhasználók figyelemmel követ- 
hetik a marketingprogramokból, 

a külső kommunikációból és a fel- 
használói igényekből származta- 
tott elvárásokat. Mindkét CRM al- 
kalmazás webes naptárat, az érté- 
kesítési feladatokról szóló önmű- 
ködő értesítéseket, testreszabható 
honlapokat és több előre meg- 
adott és dinamikus jelentést kínál. 
www.sugarcrm.com 
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Szóval, ha egy nálad okosabbat ta- 
lálsz, csak haladj tovább. A karbantar- 
tói felelősséged nagyjából olyasmire 
változik mint , Jó ötletnek hangzik — 
próbáljuk ki", vagy , Ez jól hangzik, de 
mi a helyzet xxx-el?" A második verzió 
különösen hasznos, hiszen jó alkalom 
arra, hogy valami újat megtudjunk az 
,XXX"-ről, vagy kihúzhatjuk magunkat, 
hiszen rámutattunk valamire, amire 
az okosabb ember nem Is gondolt. 
Mi mindkét esetben nyerünk. 

Linus Torvalds 

A rendszermag karbantartásról 
(Iwn.net/Articles/1053/5) 


Ha végiggondoljuk, valóban van értel- 
me. A Linux és a nyílt forrású termé- 
kek olcsóbbak, ellenállóbbak és biz- 
tonságosabbak. Amikor a Microsoft 
azt állítja az ő termékük /7CO (teljes 
bekerülési költség) értéke alacso- 
nyabb, olyan mintha azt állítaná, hogy 
a Föld lapos. A helyesen gondolkodó 
informatikai igazgatók jól tudják, hogy 
a Linux és a nyílt forrású termékek ol- 
csóbbak és aligha lehet bolonddá ten- 
ni őket szavakkal való bűvészkedéssel 
vagy gyanús, kereskedő-módosította 
ICO tanulmányokkal. 

Del Elson 

Open Source in Australia, CXO Today 
( www. cxotoday.com) 


Ha a nyílt forrás megfelelő módon 
ellenőrzött nincs nála jobb. De a kód 
elérhetővé tétele önmagában még 
nem jelent garanciát. 

Bruce Schneier 

( www. schneier.com/blog/archives/ 
2004/10/schneier securi.htm)) 


A jelenlegi tudományos kiadói model- 
lek gazdaságilag nem tarthatók. A ku- 
tatók és a tanulók csak a szükséges 
tudományos műveltség törtrészéhez 
jutnak hozzá. Azonban már folynak 

a fejlesztések és tesztek a gyógymód 
és alternatív megoldások után. 
University of California Office 

of Scholarly Communications 

(osc. universityofcalifornia.edu) 
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Láttuk-hallottuk 


A hónap szakmai tanácsai 








A Linux Journal 
honlapján számtalan 
gond megoldásához 

találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 

útmutatásokat a 

5Wwww.linuxjournal.com 
honlapon olvashatjátok 
el. A rovatban közzétett 
válaszokat Linux-szak- 
értők kis csapata készí- 
tette el. lovábbi kérdé- 
serteket szívesen fogad- 
Ják (angol nyelven) a 

5 www. Iinuxjournal. com/ 
[-Issues/techsup. html 
címen, ahol csak egy 
kérdőívet kell kitöltene- 
tek, de a bts(ossc.com 
címre levelet is írhattok. 
A levél tárgyában 
szerepeljen a ,BIS" 
kulcsszó. 
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A /etc/shadow terjesztése 

Egy segédprogramra vadászok, melynek érzé- 
sem szerint már léteznie kell valahol. Lássuk, 
mi a gondom. A kormányzati számítógépeken 
mostanában gyakrabban kell módosítani a Jel- 
szavakat, ide értve a root jelszavát Is. Eddig 
olyan sokféle géppel és operációs rendszerrel 
rendelkeztünk, hogy a /etc/shadow vagy 

a /etc/pbasswd SSH-n keresztüli átmásolása az 
összes gépre gyakorlatilag kivitelezhetetlennek 
tűnt, ugyanis minden operációs rendszer alatt 
más bejegyzések tartoznak a roothoz. Ha egy 
gépen felülírjuk a root bejegyzését egy másik 
operációs rendszer írásmódja szerint, azzal 
csak kárt okozunk. Feltételezem, hogy vakon fe- 
lülírva a fájlokat elsősorban a root héját és beje- 
lentkezési útvonalát lehetne elrontani. Az utób- 
bi időben ugyanakkor sikerült megszabadul- 
nunk a nem PC alapú - SGI, Sun, HP és egyéb 
— munkaállomásainktól, így remélhetőleg csak 
egyetlen operációs rendszerrel kell majd bajlód- 
nunk, amikor megküzdünk a vírusok és a foltok 
problémájával. Vagyis végre lehetővé válik, 
hogy a root bejegyzést az egyes gépek 
/etc/shadow vagy /etc/passwd fájljába SSH-n 
keresztül írjuk bele. 


Vajon létezik már erre eszköz? Gondolom, 

csak készült már olyan parancsfájl, amit némi 
átalakítással alkalmassá tudnék tenni a módosí- 
tások terjesztésére. A gépek egy része valami- 
lyen — DNS-kiszolgálóval is ellátott — tartomány- 
ba tartozik. A DNS-t nem futtatók MIS szolgálta- 
tást használnak. A DNS alapúakkal nem nagyon 
foglalkoztam még, de azt tudom, hogy a NIS-t 
futtatóknál még mindig helyileg kell megváltoz- 
tatni a root bejegyzését. Eddig telneten vagy 
SSH-n keresztül egyenként beléptünk minden 
gépre, így adtuk meg a root új jelszavát — nem 
is nagyon volt más lehetőségünk. A gépeken 
naprakészen kell tartani a root fiókokat, különö- 
sen, ha valamiért esetleg egyfelhasználós mód- 
ba akarnánk váltani. 

lrene Paradis 

9 Irene.paradis(9us.army.mil 


A NIS használata klasszikus megoldás er- 
re a gondra. A root Jelszava ugyanakkor 
egyetlen módszerrel kezelhető igazán Jól, 
mégpedig a /etc/shadow fájl módosításával. 
RADIUS kiszolgáló használatát is érdemes 
megfontolni. 

Christopher Wingert 

9 cwingertogualcomm.com 
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Az rdist alkalmas egy-egy fájl több gépre való 
másolására. Lásd: 5 www.magnicomp.com/jrdist 
Az Is megoldás, hogy letiltod, ,kicsillagozod" 

a root jelszavát, vagyis " karaktereket Írsz 

a s/etc/shadow fájl titkosított jelszót tartalmazó 
mezőjébe, majd mindenhez sudo-t használsz. 
Don Marti 

a ma rtOSsc GO 


Hogyan lehet kapcsolókat megadni 

a rendszermagnak? 

A 2004 novemberi számban megjelent taná- 
csok között a Fedora telepítésével kapcsola- 
tosan olvasható linux noacpi, linux 
disableapic és linux noacpi disableapic 
kapcsolók pontosan milyen célt szolgálnak? 

Két AMD MP 2800-t processzort tartalmazó 
gépem rendszeresen összeomlik. Az utolsó me- 
móriakiíratás során láttam valami acpi vagy apic 
vonatkozású dolgot - a legközelebb fel kellene 
még jegyeznem, hogy pontosan mi Is jelenik 
meg. A cikk olvasása után ki akartam próbálni 
ezeket a kapcsolókat, de nem sikerült rájön- 
nöm, hol találom őket. 

Doug Baker 

9 cfdbakerogwest.net 


A tanács az volt, hogy a noacpi vagy 

a Idisableapic vagy a noacpi disableapic kap- 
csolót parancssori kapcsolóként adjuk át a rend- 
szermagnak. Amikor a rendszertöltő, vagyis 

a GRUB vagy a LILO rákérdez, hogy melyik operá- 
ciós rendszert vagy rendszermagot akarod elindí- 
tani, módod nyílik a kapcsolók hozzáadására. 
LILO használatakor nyomd meg a Ctri-X billentyű- 
kombinációt, ezzel a parancssorba lépsz, majd Írd 
be a linux noacp parancsot. Feltételezem, hogy 
a Linux a LILO menüpontjainak egyike. Ha megol- 
dást hoz a kapcsoló használata, akkor állandó jel- 
leggel is hozzáadhatod a /etcAlilo.conf fájlhoz. 
Usman Ansari 

9 usmansansarrgyahoo.com 


A folyamat a GRUB rendszertöltő esetében 

— amely a Fedora alapértelmezett rendszertöl- 
tője — Is nagyon hasonló. Lásd a nem hivatalos 
Fedora GYK-t: wwvwv.fedorafaa.org/otherinstall. 
Don Marti 

9 dmartrXOssc.com 


A processzor tesztelése különböző 
terhelésekkel 


Munkámból fakadóan gyakran tesztelek linuxos 
gépeket. Olyan módszert keresek, amellyel fo- 
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kozatosan lehet emelni a processzor terhelését 
nulláról száz százalékra, miközben követni le- 
het, hogy mi! történik az egyes alkalmazásokkal. 
Ha megpróbálom fokozatosan növelni a pro- 
cesszorterhelést, az általában hirtelen ugrik nul- 
láról száz százalékra. Ha rövid időkre megpró- 
bálom felfüggeszteni a futtatást, akkor nulla és 
száz százalék között ugrál az igénybevétel mér- 
téke. lIudtak valamilyen eszközt erre a célra? 
Patrick Killelea 

9 pepatrick.net 


Próbálj meg olyan programot futtatni, amely va- 
lamilyen a processzort erősen terhelő feladatot, 
például véletlen számok előállítását usleep hívá- 
sokkal kever. A BUFSIZE és az USLEEP értékét 
módosítva nekem sikerült különféle processzor- 
terheléseket elérnem: 


/" A fordítás a "gcc -wall terheles.c -o 
terheles" paranccsal történik 7"/ 
finclude cstdio.hz:z 

finclude cunistd.hsz 

finclude cfcntl.hs 

fdefine BUFSIZE 1024 

fdefine USLEEP 10000 

char buflBUFSIZEI; 

int main (int argc, char "7argv) 


í 
Int í; 
f - open("/dev/urandom" , 
5350 RDONLY); 
while (1) ( 
read(f, €buf, BUFSIZE); 
us leep(USLEEP) ; 
DI 
return 0; 
Ü 


Köszönöm Greg Kroah-Hartmannek, hogy le- 
tisztázta a fenti kódot. Lásd még: man usleep. 
Ha többprocesszoros gépen egy-egy pro- 
cesszort akarsz terhelni, akkor tekintsd át 

a Robert Love a Linuxvilág 2003 szeptemberi 
számában megjelent, , Processzorhoz kötés" 
című cikkében szereplő rendszerhívásokat. 
Don Marti 

9 dmartrXOssc.com 


Egyfelhasználós mód 


Rendszertöltés közben hogyan válthatok egy- 
felhasználós, azaz első szintű futtatási módba? 
Arthur Schroeder, showmeyrogyahoo.com 
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írd át a GRUB rendszertöltő sorát, és add hozzá 
a single parancsot. 

Christopher Wingert 

9 cwingertogualcomm.com 


A LILO és a GRUB parancssorába egyaránt 
be lehet írni a single parancsot, ha egy 
linuxos gépet egyfelhasználós módban 
akarsz elindítani. Ha valamiért mindig 
egyfelhasználós módban akarod indítani a gé- 
pet, akkor a LILO vagy a GRUB beállításainak 
módosításával Is át tudod adni a single kap- 
csolót a rendszermagnak. A /etc/inittab fájl 
átírása is megoldás. Saját Red Hat 9.0 ter- 
jesztést futtató gépemen a fájl elején találha- 
tó az id:3:initdefault parancs, amelyben 
a 3-as számot kell 1-esre cserélni. 

Usman ÁAnsari 

9 usmansansarrgyahoo.com 


Lukács 5:37-38 


Új Dell Dimension 4600 gépemre próbálom 
telepíteni a Red Hat Linux 7. 1-es változatát. 

A telepítő CD elindul, majd kiválaszthatom 

a telepítés típusát. Mindegy, mit választok, 
miután a számítógép megkezdte a hardverele- 
mek felismerését, és túljutott a CD-ROM- 
meghajtón és a merevlemezeken, egyszerűen 
lefagy. A kikapcsoláson kívül semmit nem tudok 
kezdeni vele. 

Joe Pietro 

9 jm pliletror(dhotmail.com 


Mielőtt túl sok idődet fecsérelnéd el, Javas- 
lom, hogy próbálkozz meg egy újabb terjesz- 
téssel. A Red Hat 7.1 már Jó pár éves. Nagy 
valószínűséggel egy újabb terjesztéssel több 
szerencséd lesz. Én a Fedora Core 2 terjesz- 
tést ajánlom. A Fedora Core a Red Hat leszár- 
mazottja, és hagyományosan jól fut a Dell 
gépeken. A 3 www.redhat.com címről tudod 
letölteni. 

Usman Ansari 

9 usmansansarrgyahoo.com 


A Red Hat 7.1 terjesztéshez már nincs aktív 
forrás, és biztonsági frissítések sem készül- 
nek hozzá. Lehet, hogy a géped megérezte 

a biztonsági hiányosságokat? A régebbi Red 
Hat Linuxokhoz a 5 edoralegacy.org olda- 

lon találhatsz támogatást. Ha rövid idő alatt 
ellenőrizni szeretnéd, vajon a géped megfele- 
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lően működik-e, valamint használható-e Linux 
alatt Is, akkor először próbáld ki a CD-lemez- 
ről indítható, a 5 knoppix.org oldalról elérhető 
Knoppix terjesztést. 

Don Marti 

a dimarivsse Gon 


USB-soros csatolók soros kapuinak 

beállítása 

Van egy alkalmazásom, mely USB-soros átalakí- 
tókon keresztül távoli soros készülékekhez csat- 
lakozik. Van mód arra, hogy az egyes USB esz- 
közök meghatározott USB soros kapuként ke- 
rül jenek számbavételre, függetlenül az USB ka- 
puk csatlakoztatásának sorrendjétől? Azt kellene 
például elérni, hogy az x USB kapu mindig 

a /dev/usb/ttyUSBy legyen. Mivel az alkalmazást 
több mint 200 helyen fogják használni, és elő- 
fordulhat, hogy egy-egy USB-soros csatolót má- 
sikra, esetleg újabbra ki kell cserélni, az USB 
eszközök sorozatszámára alapuló megoldás 
nem az IgazI. 

Jeff Dennison 


Ha 2.6-os rendszermagot használsz, az udev 
segítségével tudsz ilyen párosításokat létrehoz- 
ni. Az egyes USB-soros egységeknél kell keres- 
ned valamilyen egyedi azonosítót, ezek alapján 
létre tudod hozni az eszközök elnevezését meg- 
adó szabályokat. Amint Írod, a sorozatszámok 
használata nem a legjobb megoldás. Próbálkozz 
az USB eszköz topológiájának követésével, 
vagy bármi más egyedi dologgal, hiszen az 
egyediség a dolog kulcsa. Ha 2.4-es rendszer- 
magot használsz, akkor csak sok szerencsét kí- 
vánhatok. A /broc/tty/drivers/usb-serial könyv- 
tárt bebarangolva megpróbálhatod kideríteni, 
hogy melyik készülék melyik /dev/ttyUSB cso- 
móponthoz csatlakozik, de nem lesz könnyű 
dolgod. Legalább találtál még egy nyomós In- 
dokot, amiért érdemes lenne áttérned a 2.6-os 
rendszermagsorozatra. 

Greg Kroah-Hartman 

9 gregekroah.com 


Fordítási kapcsolók megadása 

Gentoo alatt 

Kezdőként, stage3 .tar fájl használatával, élő 
CD-lemezről próbálom telepíteni a Gentoo ter- 
jesztést. Sikerült elindítanom ezt a fázist, és 
próbálom optimalizálni a terjesztést. Gondolom, 
hogy a GCC make esetében különféle kapcsoló- 
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kat kellene megadnom. Egyelőre csak a kez- 
déshez, illetve az alapok megértéséhez várok 
segítséget. Mit tanácsoltok? 

Rebelrouser, 5 Rebelrouseroblueyonder.co.uk 


Ha nem tudod, mit változtass meg, inkább ma- 
radj az élő CD-lemezen szereplő beállításoknál. 
Ezek a /etc/make.conf fájlban találhatók. Erről 

és a Gentoo helyes telepítéséről a terjesztés telepí- 
tési útmutatójában találsz további tájékoztatást. 
Greg Kroah-Hartman, 5 gregekroah.com 


A Fedora telepítője lefagy 

Fedora terjesztést próbálok telepíteni. Ennek so- 
rán eljutok a képernyő beállításához, ahol 256 
színt választok, majd az OK gombra kattintok. 
Ebben a pillanatban a képernyő megmerevedik, 
olvashatatlanná válik. A parancssort sem tudom 
elérni. Kérlek, segítsetek! 

Chris, 5 fistoncgeohotmail.com 


A grafikus kártya és az Xtelepítéskori beállítását 
ki Is hagyhatod. Ha a telepítés befejeződött, In- 
dítsd újra a gépet, és próbálkozz meg most az X 
beállításával. A kártyád típusát az Ispci -vvv pa- 
ranccsal derítheted ki. Ha a kártya támogatása hi- 
ányzik, látogass el a gyártó weboldalára, és ke- 
ress hozzá illesztőprogramot. 

Usman Ansari 

9 usmansansarrgyahoo.com 


Be lehet csapni az Oracle telepítőjét? 

Tudja valaki, hogyan lehetne átverni az Oracle 
109 telepítőjét, és elhitetni vele, hogy egy 
Slackware rendszer Red Hat? Így rá lehetne 
venni, hogy legalább megpróbálja a telepítést. 
Ha nem, akkor vajon hogyan jön rá, hogy nem 
Red Hat rendszeren futtatják? 

Blake Tullysmith 

9 bdtevipretech.com 


Futtasd az strace eszközt a telepítőn: 


f strace oracle-installer 
így meg tudod állapítani, hogy a program mit 
vizsgál meg, mielőtt elutasítaná a telepítést. 


Christopher Wingert 
9 cwingertogualcomm.com 


Linux Journal 2005. január, 129. szám 


Változatkezelés az Arch használatával: bevezetés 


Ha a CVS-t akarjuk felváltani, vagy komolyan gondolkozunk egy változatkezelő 
rendszer bevezetésén, íme egy hatékony eszköz, amely nyomon követi a változ- 


tatásokat és kézben tartja a projektjeinket. 


z Arch rohamosan válik az egyik leghatékonyabb 
AA eszközzé a szabad szoftvereket fejlesztő programo- 
zók eszköztárában. Ez a cikk annak a három részes 
cikksorozatnak az első tagja, amely bemutatja az Arch hasz- 
nálatát az osztott fejlesztés során, valamint megismerteti 
az olvasót a megosztott archívumok és az Arch projektekhez 
alkalmazható önműködő parancsfájlok használatával. 
Ebből a cikkből megtudhatjuk, hogyan szerezhetjük meg 
a kódot egy nyilvános Arch-archívumból, hogyan tölthetjük 
vissza a változásokat és hogyan készíthetünk helyi fejlesz- 
tési ágat a projektről kapcsolat nélküli használatra. Megis- 
merhetünk továbbá néhány technikát a helyi és távoli ar- 
chívumokkal való hatékonyabb munkára is. 





A változatkezelés története 

A változatkezelés egy projekt változásainak nyilvántartásá- 
val foglalkozik. A szabad szoftverek fejlesztése során alap- 
vető fontosságú a projekten végzett munka elemzésének, 

a fejlesztési ágak összehasonlításának, a változtatások is- 
métlésének vagy visszavonásának lehetősége. A lehetséges 
közreműködők nagy száma és a változtatások gyors kibo- 
csátása rövid időn belül életre hívta ezeknek a változtatá- 
soknak a kezelésére szolgáló eszközöket. 

A változáskezelés legősibb eszköze a szalagos tároló volt. 
Egy projekt korábbi változatait a szalagon tárolt biztonsági 
mentésekből kellett előhúzni és soronként összehasonlítani 
az új változattal. A szalagról történő beolvasása nem egy 
gyors folyamat, így ez semmilyen szempontból nem nevez- 
hető hatékony megoldásnak. 

Ennek a hátráltató tényezőnek a kiküszöbölésére sok fejlesz- 
tő kéznél tartotta a fájlok régebbi változatait is összehasonlí- 
tás céljából, és ez a lehetőség hamarosan a fejlesztőeszkö- 
zökben is megjelent. A fájlalapú változatkezelés, amelyet 
például az Emacs karakteres szerkesztő is használ, számo- 
zott biztonsági másolatokat őriz a fájlokról, így ha meg akar- 
juk vizsgálni a változtatásokat, könnyedén összehasonlíthat- 
juk a foo.c—7- fájlt a foo.c—8— fájllal. Néhány korai keres- 
kedelmi operációs rendszerben még a fájlrendszer szintjén 
is megjelentek ezek a számozott biztonsági másolatfájlok. 
Közel két évtizeden keresztül a szabad programok külső fej- 
lesztői által előszeretettel alkalmazott formátum a foltfájl volt, 
amit különbségfájlként is emlegettek. Két fájlt összehasonlítva 
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egy erre a célra fejlesztett különbségképző program állította 
elő azt a listát, amely a két fájl eltéréseit emelte ki. A kimenet- 
ként előálló különbségfáj! által tartalmazott eltérések jóváha- 
gyásához csak egy foltozó programon kellett lefuttatni a fájlt. 
A 90-es évektől a CVS (Concurrent Versions System), párhu- 
zamos változatkezelő rendszer) vált a fejlesztők egy köz- 
ponti csoportja által alkalmazott alapértelmezett változás- 
kezelő rendszerré. Egy egyszerű ágkövető és egyesítő rend- 
szer teszi lehetővé a felhasználó számára a különböző 
fejlesztési ágakkal történő kísérletezést, majd a sikeres 
próbálkozások főprojektben történő rögzítését. 

A CVS-nek megvannak a maga korlátai, amelyek sok pro- 
jekt számára egyre inkább terhet jelentenek. Először is 

a rendszer egyáltalán nem tárolja az olyan metaadatok 
megváltozását, mint a fájlokhoz kötődő jogosultságok vagy 
a fájl nevének a megváltozása. Ilyen hiányosság az is, hogy 
a bejegyzések nem kapcsolhatók össze, így igen nehézkes 

a több fájlon vagy könyvtáron átívelő változások követése. 
Végül majdnem minden távoli CVS-táron végrehajtott mű- 
velet egy újabb kapcsolat megnyitását igényli a kiszolgáló 
felé, megnehezítve ezzel a kapcsolat nélküli munkát. 

A Subversion Projekthez hasonló erőfeszítések nagy utat 
tettek meg a CVS-ben fellelhető hiányok kiküszöbölése felé 
vezető úton. A Subversion lényegét tekintve egy CVS-t -, 
amely támogatja a metaadatok változásának rögzítését és 
az elemi bejegyzéseket. lovábbra is szükség van azonban 
egy olyan központi kiszolgálóra a hálózaton, amelyhez az 
összes változáskezelésben részt vevő ügyfélgép csatlakozik. 


A megosztott változáskezelő rendszerek 

Az utóbbi néhány évben a változáskezelő rendszereknek egy 
új generációja látott napvilágot, amelyek mindegyike az osz- 
tott modellt alkalmazza. Az osztott változáskezelő rendsze- 
rek szakítanak a központosított tárhely elvével, ehelyett az 
egyenrangú gépek alkotta elrendezést részesítik előnyben. 
Minden fejlesztő fenntartja a maga tárolóhelyét, a rendelke- 
zésre álló eszközök pedig lehetővé teszik a végrehajtott vál- 
toztatások egyszerű átadását a hálózaton lévő gépek között. 
A Monotone, a DARCS az Arch és a hasonló projektek olyan 
környezetben tettek szert nagy népszerűségre, ahol a sza- 
bad forráskódú fejlesztés a jól összekapcsolt egyetemeken 
kívül zajlik, és a noteszgépek sokkal elterjedtebbek. 
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Jelen pillanatban az osztott rendszerek egyik legígéretesebb 
darabja a GNU Arch. Az Arch úgy bonyolítja a kapcsolat nél- 
küli használatot, hogy a felhasználókat helyi másolatok lét- 
rehozására ösztönzi és hatékony eszközöket kínál a projek- 
tek archívumok közti mozgatására. Az Arch-ból hiányzik 
bármiféle kizárólagos kiszolgálói folyamat, az archívum 
kezelésére pedig a fájlrendszer-műveletek egy hordozható 
részhalmazát használja. Az archívumok egyszerűen olyan 
könyvtárak, amelyeket a hálózaton az általunk választott 
fájlrendszer-protokoll segítségével teszünk elérhetővé. 

Mi több, az Arch támogatja az archívumok HITP, FIP vagy 
SFIP protokollokon keresztül történő elérését. Az egyik 
nagy előnye annak, hogy nincs egy kitüntetett démon, hogy 
nem kap egy új program jogokat a kiszolgáló gépünkön. 

Így a biztonsággal kapcsolatos kérdések csak az SSH démon- 
nal vagy a webkiszolgálóval lesznek kapcsolatban, amin 

a legtöbb rendszergazda amúgy is rajta tartja a szemét. 

Egy másik előny, hogy az Arch használatakor a legtöbb fel- 
adat megoldásához nincs szükség a root jogosultságaira. 

A fejlesztők elkezdhetik csak a saját gépeiken használni és ar- 
chívumokat tehetnek közzé anélkül, hogy akár csak telepíteni 
kellene az Arch-ot a webkiszolgáló gépen. Ez hatással van az 
alkalmazás módjára is: míg a CVS vagy a Subversion haszná- 
lata egy felülről lefelé irányuló döntés, amely a teljes projekt- 
csapatra vonatkozik, az Arch-ot alkalmazhatja csupán egy-két 
fejlesztő is a csapatban, míg át nem áll a többi tag is. 


Hogyan juthatunk a tla-hoz? 

Az Arch eredetileg Iom Lord hackerlab programkönyvtárai- 
hoz tartozó burkoló- és héjprogram-gyűjtemény volt. Abban 
az időben a programot larch néven emlegették és egy kicsit 
esetlenül lehetett használni. Az ügyfél C nyelven teljesen át 
lett írva, a neve pedig fla lett (Iom Lord" Arch). A felülete 
még mindig nem tökéletes, de arra megfelel, hogy egy kép- 
zett fejlesztő normál módon használja a napi munkájához. 
A tla csomagjai a legtöbb GNU/Linux rendszercsomaghoz 
elérhetőek (források: 5 www.linuxjournal.comjarticle/7752). 


Égy csak olvasható projekt letöltése 

Miután feltelepítettük a tla-t, nem árt, ha valamilyen letöltött 
kóddal ki is próbáljuk. Az Arch az adatainkat egy könyvtár- 
ban tárolja, amit archívumnak nevezünk. Egy archívumon 
belül az adataink egymásba ágyazott kategóriákban helyez- 
kednek el: ezek a projektek (ez az egész munkának a neve), 
az ágak (a fejlesztés vagy valamilyen egyéb leíró elem egy bi- 
zonyos ága, és a változatok (egy egyszerű szám, amelyet an- 
nak a jelölésére használhatunk, hogy egy bizonyos szál fej- 
lesztésében milyen messze sikerült előrehaladnunk). A kód- 
hoz jutás első lépése egy nyilvános archívum regisztrálása, 
így az Arch egy nevet tud rendelni az archívum helyéhez: 


$ tla register-archive http: //ww. Inx-bbc.org/arch 

Ezt követően a tla archives parancs futtatása után látnunk 

kell az Inx-bbc-develázork .net--gar archívumot Ha kíván- 
csiak vagyunk, hogy itt milyen projektek tárolása történik, 


a teljes lista lekérésére használhatjuk a tla abrowse parancsot. 


$ tla abrowse Inx-bbc-develdzork.net--gar 
1]nx-bbc-develdzork.net--gar 
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Szaktekintély [NNNNNNNNNNNI.. bbebvbL//é5 ss ,,sősss555őős 


Inx-bbc 
1]nx-bbc--research 
1]nx-bbc--research--0.0 
base-0O .. patch-10 


1]Inx-bbc--stable 
1]lnx-bbc--stable--2.1 
base-0O .. patch-29 


scripts 
scripts--gargoyle-bin 
scripts--gargoyle-bin--1.0 
base-0O .. patch-7 


Ebből a listából az látható, hogy a Inx-bbc-develzork.net- 
-gar archívum két projektet tartalmaz Inx-bbc és scripts 
néven. Az Inx-bbc két ággal rendelkezik: research (kísérleti) 
és stable (stabil). Az Inx-bbc--research ágnak csak egy 
változata van (0.0), amelynek tíz változtatását tartalmazza az 
archívum. Az Inx-bbc--stable egy változattal (2.1) és 29 
változással szerepel. 

Mivel most már rendelkezünk az LNX-BBC regisztrált archí- 
vumával a helyi listánkban, nincs akadálya annak, hogy 
letöltsük az LNX-BBC stabil ágának egy másolatát: 


$ tlaget A 
Inx-bbc-develézork.net--gar/]nx-bbc--stable Inxbbc 


Amikor befejeződött a letöltés és a foltok alkalmazása, kell 
lennie egy Inxbbc/ könyvtárunknak tele mindenféle fájllal. 
legyünk úgy, mintha megváltoztatnánk a kódot: lépjünk 
be az Inxbbc/ könyvtárba és írjunk be valahova egy új 
megjegyzést. 


Változtatások hozzáadása 

Miután megváltoztattuk a fájlt, a tla what-changed pa- 
rancsnak ki kell írnia egy M robots . txt sort, jelezve, hogy 

a robots . txt tartalma megváltozott. A változás részleteit 

a tlawhat-changed --diffs paranccsal kérhetjük le, amely 
kilistáz egy különbségfájlt készen arra, hogy visszaküldjük 
a projekt fejlesztőcsapatának. 


--- orig/robots.txt 

tt mod/robots.txt 

aa -1,3 41,5 Aa 

rítt Welcome, robots! 

£ 
User-agent: " 
Disallow: /garchive/ 
Disallow: /cgi-bin/ 


Ennek a módszernek a hátránya, hogy a különbségfájl nem 
jelzi a metaadatokban bekövetkezett változásokat: az eltávo- 
lított és új fájlok nem fognak megjelenni, amikor egy másik 
fejlesztő lefuttatja a különbség-foltunkat. Ahhoz, hogy a pro- 
jekt kezelőinek egy bonyolultabb változtatást át tudjunk ad- 
ni, egy változáskészletet (changeset) kell létrehoznunk. 

Az Arch-ban egy változáskészlet a teljes könyvtárszerkeze- 
tet jelenti a fájlok változásainak, a foltoknak, az új és eltávo- 
lított fájloknak a teljes nyilvántartásával. A közreműködés 


legjobb módszere az, ha létrehozunk egy változáskészlet- 
könyvtárat és ezt összecsomagoljuk a továbbításhoz: 


$ tla changes -o , ,new-robot-comment 
$ tar czvf my-changes.tar.gz , , new-robot-comment/ 


Az Arch nem veszi figyelembe a két veszővel, egyenlőségjellel 
és még néhány különleges karakterrel kezdődő fájlneveket. 
Azzal, hogy elhelyezzük a ,, jelet a változáskészletünk könyv- 
tárnevének az elején, elkerüljük, hogy az Arch kifogásolja, 
hogy az új könyvtárunk még nem létezik az archívumban. 

A gyakorlatban hasznos lehet az elektronikus levélcímünk 
vagy valamilyen más azonosítónk feltüntetése a tar-csomag 
fájlnevében és a változáskészlet könyvtárának a nevében. 


Az archívum frissen tartása 

Időnként szükségünk lesz a projekt legfrissebb változtatása- 
inak letöltésére. Ez nem jelent bonyolultabb feladatot, mint 
a tla update parancs futtatását a letöltött másolatban. 

Az Arch először egy tla undo parancs végrehajtásával biz- 
tonságba helyezi a helyi változtatásainkat, mielőtt az új 
változáskészleteket alkalmazná. Miután feltette az összes 
foltot, lefuttatja a tla redo parancsot a helyi változások 
visszaállítására. 

A korábban bemutatott minden tla parancshoz szükség 
van egy élő hálózati kapcsolatra az archívumot tároló Inx- 
bbc. org rendszerhez. A kapcsolat nélküli használathoz lét- 
re kell hoznunk egy helyi archívumot és ezen belül egy fej- 
lesztési ágat. 


Egy archívum létrehozása 

Mielőtt dolgozni kezdenénk egy írható-olvasható archí- 
vumban, azonosítanunk kell magunkat a tla számára: 
$ tla my-id "J. Random Hacker cjrhézork.net:" 

A levélcímünk megadása után elérkezett az idő, hogy archí- 
vumot készítsünk a projektjeink számára. Az Arch több ar- 
chívum létrehozását is lehetővé teszi, de egy archívumon 
belül is tetszőleges számú projekt és fejlesztési ág tárolására 
van lehetőség. 

Az archívumok neve két részből áll, amelyet kettős kötőjel- 
lel választunk el egymástól: az első rész az elektronikus le- 
vélcímünk, a második pedig valamilyen azonosító. Sok fej- 
lesztő azonosítóként az évszámot adja meg és minden év- 
ben új archívumot kezd: 


$ tla make-archive -1] jrházork.net--2004 -/ARCHIVE 
$ tla my-default-archive jrházork.net--2004 


A my-default-archive paranccsal megadva az alapértel- 
mezett archívumunkat a helyi archívumon végrehajtandó 
műveletek begépelését könnyíthetjük meg. 


Fejlesztési ág létrehozása 

Az Arch arra ösztönzi a felhasználókat, hogy a fejlesztési ágak 
használatával ágaztassák el és fésüljék össze a projekteket. Az 
ágak jelentik az elsődleges módszert a kód egyik archívumból 


a másikba történő mozgatására akár hálózaton keresztül is. 
A fejlesztési ágakat használhatjuk a projekt egy teljesen új fej- 
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lesztési irányát tartalmazó teljes kód változásának nyomon 
követésére, de alkalmazhatjuk arra is, hogy a projektünk egy 
átmeneti másolatát hozzuk létre a noteszgépünkön, amelyen 
hálózati kapcsolat nélküli környezetben is dolgozhatunk. 

A nyilvánossá tett ágak jelentik a fejlesztéssel kapcsolatos 
párbeszéd elsődleges eszközét is az Arch-ot használó fejlesz- 
tők között. Ahelyett, hogy levélben küldözgetnének nagy 
méretű tar-csomagokat egymásnak, a közreműködő valószí- 
nűleg inkább egy ágat hoz létre a helyi változások tárolására, 
és arra kéri fel a fejlesztőket, hogy fésüljék bele ezeket a vál- 
toztatásokat a fő projektbe. Itt ragyog fel leginkább az Arch 
decentralizált és demokratikus természete: bárki csatlakozhat 
a fejlesztéshez anélkül, hogy ehhez a központi fejlesztőcsa- 
pattól valamilyen különleges jogosultságot kellene kapnia. 
Mielőtt elágaztatnánk az Inx-bbc projektet, helyet kell biz- 
tosítanunk a projekt számára az archívumunkban. A projekt 
azonosítója az archívum nevéhez hasonlóan épül fel: a kate- 
gória (vagy projektnév), két kötőjel, az ág neve, két kötőjel 
és a verziószám. Valószínűleg Jom Lord LISP-szakértői ta- 
pasztalata vezetett ezeknek a kötőjeleknek a használatához: 


$ tla archive-setup Ilnx-bbc--robot-branch--0.0 


Ezzel létrejön az Inc-bbc nevű kategória a robot-branch 
nevű fejlesztési ággal 0.0 verziószámmal. A jrhűzork.net- 
-2004/ archívum-nevet nem kell megadnunk a projekt ne- 
ve előtt, mivel ez az alapértelmezett archívumunk. 


A fejlesztési ágak címkézése 

Végül elérkezett az idő arra, hogy felcímkézzük az águnkat. 
Ez annyit jelent, hogy a robot-branch egy címkével kezdő- 
dik, amely az Inx-bbc-develázork . net--gar archívumban 
lévő egy projekt adott változatára mutat, a helyi változtatá- 
sok pedig ettől a ponttól kezdődnek: 


$ tla tag N 
1Inx-bbc-develázork.net--gar/]nx-bbc--stable--2. 1. A 
Inx-bbc--robot-branch--0.0 


Ha itt futtatjuk a tla abrowse parancsot, az archívumunk- 
ról a következő képet kell mutatnia: 


jrhaázork.net--2004 
Inx-bbc 
Inx-bbc--robot-branch 
Inx-bbc--robot-branch--0.0 
base-0 


Az új fejlesztési ág használatha vétele 
Most már készen állunk arra, hogy letöltsük az új águnk 
egy másolatát: 


$ tla get Inx-bbc--robot-branch robot-branch 


Itt beléphetünk a robot-branch könyvtárba és módosítha- 
tunk egy-két dolgot: 


$ chmod 444 index.txt 


$ tla mv fag.txt robofag.txt 
$ echo "ROBOT TIME" 5 robot-time 
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$ tla add robot-time 
$ tla rm ports.txt 


A tla mv parancs olyan módon módosítja egy fájl nevét, 
hogy az Arch képes legyen a fájl változásának nyomon kö- 
vetésére. Fontos, hogy ezt a parancsot használjuk a szabvá- 
nyos mv helyett. A tla add parancs előkészíti egy fájl hozzá- 
adását az archívumhoz, a tla rm pedig egy fájl eltávolításá- 
nak tervét rögzíti. Ezek a változások most már megjelenít- 
hetők a helyi fejlesztési ágban: 


$ tla commit 


Elindul a kedvenc karakteres szerkesztőnk (a korábban 

a $EDITOR környezeti változóban megadottaknak megfele- 
lően) egy végrehajtási jegyzőkönyv sablonját kínálva. Miu- 
tán kitöltöttük a bejegyzéseket, a mentéssel és kilépéssel 
véglegesítjük a változtatásokat. 

A tla abrowse parancsot kiadva láthatóvá válik, hogy most 
már két változata létezik az archívumunkban lévő robot 
ágnak, a base-0 és a patch-1: 


jrhaázork.net--2004 
Inx-bbc 
Inx-bbc--robot-branch 
Inx-bbc--robot-branch--0.0 
base-0O .. patch-1 


Egy projekt összefésülése két különböző archívumból 
lermészetesen, mialatt a saját águnkon dolgozunk, az ere- 
deti archívumban is folytatódhat a munka. A tla update 
parancs futtatása csak a helyi ágból olvassa ki a változtatá- 
sokat, az eredeti projektből nem. A központi archívumból 
a star .merge paranccsal tudjuk a változtatásokat átemelni: 


$ tla star-merge NM 
1]nx-bbc-develázork .net--gar/]nx-bbc--stable--2.1 


Ütközések esetén (amikor a saját águnk és a központi pro- 
jekt is tartalmaz változtatásokat ugyanazokra a kódsorokra 
vonatkozóan) az Arch az eredeti foltozási eljárást használja, 
amelynek során létrehozza a megfelelő .orig és .rej kiter- 
jesztésű fájlokat. Érdemes egy keresést végrehajtani 

a visszautasításokat tartalmazó fájlokra, mielőtt a star- 
merge parancs változtatásait véglegesítenénk. 


Az archívum-műveletek felgyorsítása 

Észrevehettük, hogy az egyes változatok vagy base-0 vagy 
patch-i néven szerepelnek, ahol a tt jelenti a base-0O-ra al- 
kalmazandó változtatások sorszámát. Az Arch napló-rend- 
szerű archiválási formátumot alkalmaz, így rögzíti a projekt- 
hez kötődő bármilyen információ változását. Ez azt is jelen- 
ti, hogy a nagyméretű, sok változattal rendelkező projektek 
esetén bizonyos feladatok végrehajtása hosszú időt vehet 
igénybe. A műveletek meggyorsítására pillanatképet készít- 
hetünk egy adott változatról. Az Arch pillanatképei egy köz- 
zétett változatról készült egyszerű tömörített tar-csomagok. 
Amikor valamilyen műveletet végrehajtunk, az Arch megke- 
resi a legmagasabb sorszámmal rendelkező pillanatképet és 
a szükséges változtatásokat ettől kezdve hajtja végre: 
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$ tla cacherev 


Ennek befejezése után futtathatjuk a tla chachedrevs pa- 
rancsot, hogy lássuk, milyen pillanatképekkel rendelkezünk 
az archívumunkban: 


1Inx-bbc--robot-branch--0.0--base-0 
Inx-bbc--robot-branch--0.0--patch-1 


A könyvtárak 

Mivel nem mindig rendelkezünk megfelelő jogosultsággal 
az archívumban a pillanatképek készítéséhez, hasznos lehet 
helyi képeket létrehozni a fájlműveletek felgyorsítása érde- 
kében. Az Arch egy másik fajta pillanatképet is támogat, 
amelyet könyvtárnak (library) nevez, s amely a különböző 
ágakból származó közzétett fájlokat tartalmazza. Ez különö- 
sen a távoli archívumoknál hatékony, mivel így még egy 
változat alapképét sem kell letöltenünk ahhoz, hogy alkal- 
mazzuk a változáscsomagunkat: 


$ mkdir -/LIBRARY 
$ tla my-revision-library -/LIBRARY 
$ tla library-config --greedy -/LIBRARY 
$ tla Tibrary-add NM 
1Inx-bbc-develázork. net--gar/]nx-bbc--stable--2.1 


Ez a könyvtár nem éppen kis méretű, a fenti példához 
tartozó csomag 78 MB méretű volt 2004 júniusában, de 
egy lassú kapcsolat esetén a dolog bőven megéri a fáradsá- 
got. Ráadásul a hordozható gépek gyakran lassú ATA me- 
revlemezes egységgel rendelkeznek, az archívummal kap- 
csolatos műveletek pedig nagy terhelést jelenthetnek, mi- 
vel az IDE meghajtók sok processzoridőt igényelnek. 

Egy önműködően frissülő Arch-könyvtár gyorsabbá és 
reaktívabbá teszi változáskezelő műveleteinket még a he- 
lyi archívumok esetén is. 


Folytatás következik 

A sorozat következő cikkében azt fogjuk megtanulni, 
hogyan készíthetünk nyilvánosan elérhető tükrözéseket, 
amellyel a központi fejlesztők a fejlesztési ágainkból vissza- 
emelhetik a változásokat. Azt is megtanuljuk, hogyan válo- 
gathatunk egy sűrűn változó ág változáskészleteiből, és ho- 
gyan tudjuk a változáskészleteinket biztonsági célból krip- 
tográfiai módszerrel megjelölni a GnuuPG segítségével. 

A sorozat harmadik, befejező részében az Arch központi 
fejlesztéseket támogató eljárásairól lesz szó. Megtanuljuk, 
hogyan kezelhetünk megosztott hozzáférésű archívumo- 
kat az OpenSSH SFIP protokolljával, és hogyan írhatunk 
parancsfájlokat az archívum feladatainak önműködő 
végrehajtására. 


Linux Journal 2004. november, 127. szám 


Nick Moffit, Linux szakértő, Sun Francisco Bay- 
negyedében él. A GNU/Linux LNX-BBC Bootable 
Business Card csomagjának szerkesztő mérnö- 
ke, valamint a GAR szerkesztőrendszer szerzője. 
Amikor nem a rendszereivel foglalkozik, a városi 
tömegközlekedés történetét tanulmányozza. 





Linux a Linksys Wi-Fi útválasztóin 


Ennek a megbízható és költséghatékony platformnak a meghódítása lehet az első 
lépés egy vezeték nélküli projekt sikere felé. Ha például egy nagyobb területet 
akarunk lefedni, összeköthetjük a hozzáférési pontokat, a flash-memóriában 
nagyobb munkaterületet alakíthatunk ki, mesterségesen fölcsavarhatjuk a teljesít- 


ményszabályzót, és így tovább. 


vezeték nélküli hálózati megoldások tömegcikké 
AA váltak. Ma már egy 802.11-es szabványnak megfe- 
lelő vagy más néven Wi-Fi eszköz teljesen hétköz- 
napi terméknek számít. Több ezer rivális gyártó verseng 
látszólag megegyező termékeivel a Wi-Fi piacon a pénzün- 
kért. Ilyen forrongó területen természetes, ha a gyártók 
a legolcsóbb megoldásokat keresik. És mit választanak 
ennek érdekében? lermészetesen a Linuxot. 
Napjainkra a Linux vált az olcsó, többfunkciós, vezeték 
nélküli hálózatépítés elsődleges operációs rendszerévé. 
A terület egyik legnagyobb szereplője, a Linksys a követ- 
kező generációs 802.11g Wi-Fi eszközeivel a Linux felé 
fordult. Amikor 2003 elején a Cisco megvásárolta 
a Linksyst, hozományként megkapta a linuxos eszközö- 
ket, velük pedig egy a kiadatlan GPL-kódok felett foly- 
tatott elhúzódó vitát. A nyílt forráskód híveinek néhány 
hónapos lobbizása után a Cisco megenyhült és nyilvános- 
ságra hozta a forráskódot. 
A Linksys WRIT54G termékét (1. kép) az alacsony ár és 
a beépített hardver teszi különösen érdekessé. 
A WR154G-nek része egy négykapus Ethernet elosztó, 
egy Ethernet WAN kapu, támogatja az új nagy sebességű 
54 MB/s 802.11g vezeték nélküli protokollt, és megfelel 
a korábbi 802.11b eszközökkel szemben támasztott köve- 
telményeknek is. 
Mégis az teszi igazán érdekessé a WR1I54G-t, amit hiányol- 
hatunk belőle. A motorháztető alatt egy 125 MHz-es MIPS 
processzor duruzsol 16 MB RAM-mal. Ennek teljesítménye 
bőven elég lenne néhány komolyabb alkalmazás futtatására 
is, miért ne adjunk tehát hozzá néhányat? 





A fejlesztőkörnyezet üzembe helyezése 

A Linksys honlapján található legfrissebb forráskód 

145 MB-os és teljes eszközláncot biztosít a MIPS-re törté- 
nő keresztfejlesztéshez. 

Kövessük a WR154G/src alkönyvtár README nevű £ájl- 
jának utasításait a közvetett hivatkozás és a PATH- 
kiegészítések létrehozásához, majd lépjünk be a router 
alkönyvtárba és futtassuk a make menuconfig parancsot. 
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1. kép A 100 dollár alatti áron elérhető Linksys WRT54G a 16 MB 
memóriájával és 125 MHz-es processzorával egy alkalmas Linux- 
platform, amely támogatja a 802.11b és g protokollokat. 


Az első fordításunkhoz hagyjuk meg az alapbeállításo- 
kat, és kattintgassunk végig a lehetőségeken a saját 
beállítófájljaink létrehozásához. Lépjünk feljebb egy 
könyvtárszinttel a WR1I54G/src alkönyvtárba, majd adjuk 
ki a make parancsot. Ennyi az egész. A WRI54G/image 
könyvtárban létrejött egy code.bin fájl, amely egy tömörí- 
tett cramfs fájlrendszert és egy 2.4.20-as Linux rendszer- 
magot tartalmaz. 

Most következik a dolog rémisztő része: hogyan tudjuk 
ezt az új firmware-t a Linksys-re juttatni? Két eljárás is 
létezik erre, az egyik a tftp, a másik pedig a web-alapú 
firmware-tfrissítő csatlakozófelület. Azt javaslom, hogy el- 
ső alkalommal a webes frissítéssel próbálkozzunk. Adjuk 
meg a Linksys dobozunk címét - ennek alapértelmezett 
értéke 198.168.1.1 —, és jelentkezzünk be. Válasszuk ki az 
Administration (Felügyelet) menü Firmware Upgrade 
(Firmware Frissítés) menüpontját, majd töltsük fel 

a code.bin fájlunkat. Az útválasztó újraindul. Gratulálok, 
épen most ,moddoltuk" a Linksys-dobozunkat. 
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A Piny-trükk 

A WR154G-n lévő Linux létezésének felfedezéséhez egy 

a Diagnostics (Hibakeresés) menü ping eszközében lévő 
hiba vezetett el. Az 1.42.2-nél korábbi változatok megen- 
gedték tetszőleges kód futtatását a ping ablakából, 
amennyiben back-tick operátorok közé tettük. Ha egy ko- 
rábbi firmware-rel rendelkező készülékünk van, próbáljuk 
meg begépelni az 


ls -1 / 


parancsot a ping ablak IP-cím mezőjébe. És íme, csodálatos 
módon megjelenik a gyökérkönyvtár tartalma. 

A ping-trükk a kíváncsiaknak lehetővé teszi, hogy a for- 
ráskód módosítása nélkül fedezzék fel a készüléküket. 

A felfedezésnek ez a módja azonban lassú és unalmas. 
Igazából egy a készüléken futó parancshéjra lenne szük- 
ségünk. A ping-trükk forráskódban történő kiterjesztésé- 
vel egy olyan egyedi firmware-képfájl hozható létre, 
amely hálózatos felületen keresztül is rendelkezik 

a Linux héj teljes hatékonyságával. A parancshéj elké- 
szítésének leírását a hálózaton keresztül elérhető forrás- 
címek között találjuk meg. 

De miért állnánk meg itt? Az eredeti firmware carmfs fájl- 
rendszere 200K szabad helyet hagy a flash-memóriában. 
Helyet találhat itt magának egy sereg hasznos alkalmazás, 
akár egy telnet program, egy Secure Shell (Biztonságos 
parancshéj), esetleg egy VPN ügyfél vagy kiszolgáló. 


A wi parancs 

Az egyik hasznos parancs, amit a Linksys csak bináris for- 
mában szolgáltat a wl. A w] parancs több tucat olyan beépí- 
tett parancsot tartalmaz, amellyel a vezeték nélküli beállítá- 
sokat vezérelhetjük, beleértve a népszerű teljesítményt sza- 
bályozó beállítást is. A wI parancs paraméter nélküli beírá- 
sával egy teljes listát kapunk a képességeiről. 

A WRI54G alapértelmezett teljesítménybeállítása 28 milli- 
watt, és ez a beállítás kívülről nem is állítható. A ping-trükk 
vagy egy parancshéj segítségével azonban használhatjuk 

a wl parancsot, paraméterként megadva utána a txpwr 
alparancsot és az 1 és 84 milliwatt közti teljesítményértéket. 
Ez az érték a következő újraindításig megemeli vagy csök- 
kenti az alapértelmezett teljesítménybeállítást. 

A teljesítmény növelése, vagy a beépített antenna cseréje 
növelheti a kisugárzott teljesítményt, amivel megsérthetjük 
az erre vonatkozó helyi szabályokat. Ha kicseréljük az an- 
tennákat és csökkentjük a teljesítményt, akkor úgy tudjuk 
jelentősen megnövelni az egység hatótávolságát, hogy ez- 
zel nem sértjük az engedélyezett sugárzási teljesítményre 
vonatkozó helyi előírásokat. 

A WRI54G két külső antennát támogat, és önműködően 
választ a kettő közül attól függően, hogy melyikkel fogta 
be a legutóbbi aktív adatcsomagot. Amikor egy új, nagyobb 
hatékonyságú antennát szerelünk fel, nyilván nem ezt a be- 
állítást szeretnénk használni, hanem minden alkalommal 

a nagyobb teljesítményű antenna használatára szeretnénk 
a készüléket utasítani. Ezt a bejövő adatok esetén a w! 
txant paranccsal, küldésre pedig aw! antdiv paranccsal 
tehetjük meg. A 0 paraméter a bal oldali antennát jelöli ki, 
az 1 pedig a jobb oldalit, ha elölről nézzük a készüléket. 
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Az SSH (biztonsági parancshéj) telepítése 

Egy vállalkozó szellemű felhasználó a teljes OpenSSH esz- 
közkészletet átültette a Linksys készülékébe. Sajnos az 
OpenSSH bináris állományának mérete miatt sok alapvető 
Linksys funkciót is el kellett távolítani a megfelelő méretű 
szabad hely létrehozásához, ráadásul a kapott RAM-igény 

is a rendelkezésre álló memória határán volt. Igazából egy 
kis memóriaigényű SSH-kiszolgálóra lenne szükség, s ezt 

az igényt a Dropbear kiszolgáló szépen teljesíti is. Matt 
Johnson a Dropbear SSH-démont kifejezetten olyan, szűkös 
memóriával rendelkező eszközökön való futtatásra tervezte, 
mint amilyen a Linksys. Az eredeti Linksys Linux megvalósí- 
tásából hiányzik egy sereg olyan alapvető fájl, ami a többfel- 
használós Linux rendszereken nélkülözhetetlen. Ezek közül 
kettő — a /etc könyvtárban lévő passwd és groups — a Linux 
alkalmazások többségének futtatásához mindenképpen 
szükséges. Ahhoz, hogy futtatni tudjuk a Dropbear kiszolgá- 
lót, ezeket a fájlokat hozzá kell adnunk a flash-csomaghoz. 
Egy jelszóval nem rendelkező root bejegyzést tartalmazó 
passwd fájl és egy megfelelő groups fájl létrehozásával már 
majdnem alkalmas is a környezet a Dropbear futtatására. 
Ezek a fájlok a flash képfájl /etc könyvtárába kerülnek és 

a Linksys-en csak olvashatóak. 

Futtatás közben a Dropbear ezeken kívül igényli a nyilvános 
kulcshoz való hozzáférést, amely az SSH kapcsolatfelvétel- 
hez és hitelesítéshez szükséges, valamint a known hosts 
fájlt, amely az elfogadandó ügyfélgépek nyilvános kulcsait 
tartalmazza. A dropbearkey programmal egy pillanat alatt 
létrehozhatjuk a saját kulcsunkat, de a kulcs tárolása 

a Linksys-en már egy kicsit trükkösebb. 

A WRTS4G egy hash-térképet tartalmaz a kulcsok név-érték 
párjaival, amelyek egy nvram-nak nevezett nem felejtő me- 
móriában tárolódnak. A kapott nvram segédprogram és API 
lehetővé teszi, hogy írjuk és olvassuk ezt a memóriaterüle- 
tet. A Dropbear saját kulcsát és a saját .ss4 könyvtárunkban 
tárolt id rsa.pub fájlban lévő nyilvános kulcsunkat az 
nvram-ban tároljuk és rendszerindításkor innen másoljuk 
a memóriában lévő virtuális lemezre. 

Lefordítjuk a Dropbeart a kulcsfájl-hitelesítés beállításával, 
és máris biztonságos módszerünk van a Linksys-re történő 
bejelentkezéshez. Ha jelszavas belépésre van szükségünk, 
egy folttal kiegészítve a Dropbear kódját rávehetjük, hogy 
a rendszerjelszót olvassa ki az nvram-ból, és így lehetővé 
válik a jelszavas bejelentkezés is. 


A Flash-memória tömörítésének növelése 

Az SSH és a telnetd programokhoz hasonló eszközök tele- 
pítése után hamarosan tapasztalni fogjuk, hogy a Linksys 
firmware képfájlja feszegetni kezdi az eszközben lévő falsh- 
memória tárolókapacitásának határait. Szükségünk lenne 
egy olyan fájlrendszerre, ami jobb tömörítést nyújt, mint 

a cramfs és egyúttal megfelel a Linksys Linux rendszermag 
elvárásainak is. 

Az alapértelmezett cramfs fájlrendszer 4K méretű blok- 
kokba tömöríti az adatokat, ez a 4K mérethatár azonban 
korlátozza az elérhető tömörítési arányt. Ha találnánk 
egy olyan fájlrendszert, ami nagyobb adatblokkokat hasz- 
nál, de a hozzárendelése megfelel az operációs rendszer 
oldalméretének, sokkal több adatot és programot tudnánk 
tárolni a firmware-ben. 


Philip Lougher sgashfs fájlrendszere 32K méretű adatblok- 
kokat használ a tömörítéshez és megfelel a 2.4 és 2.6-os 
rendszermagoknak. Ha szerét ejthetnénk a Linksys 
firmware cramfs-ről sguashfs-re történő átültetésének, talán 
elég helyünk lenne arra, hogy egy VPN ügyfelet és kiszol- 
gálót is telepítsünk a rendszerre. 

A Linksys rendszermagja egy 2.4.20 verziójú rendszer- 
mag, amelyet a Broadcom írt át. A Broadcom cég vezető 
szerepet tölt be a 802.11g áramköri lapkák gyártásában 

és a WR154G-ben lévő központi egység és rádióáramkör 
is a munkáját dicséri. A sguashfs tar-fájlja tartalmaz folto- 
kat a 2.4.20-tól a 2.4.22-ig terjedő rendszermagokhoz, 

de sajnos ezek közül egyik sem alkalmazható teljesen 

a Broadcom rendszermag-fájához, ezért egy kis manuális 
beavatkozásra is szükség lesz. A legkevesebb hibát tartal- 
mazó folt a 2.4.22-es változat, ez az alkalmazásakor csak 
egy kódrészletet hiányol. A folt fájljának elolvasásával és 
a hiányzó darab megkeresésével kézzel módosíthatjuk 

a kódot. A Sveasoft honlapján találhatunk egy WR1I54G- 
hez készült sguashfs-foltot is. 

A következő lépés a Broadcom rendszermag indítókódjának 
a szerkesztése és egy sguashfs ellenőrzőrész hozzáadása. 

A do mount.c fájl szinte ugyanazt a kódot tartalmazza és 
jól használható, amikor az arch/mips/brcm-boards/bcm947xx 
könyvtárban lévő startup.c fájlt frissítjük. 

A rendszermag megfoltozása után az útválasztó Makefile- 
ját kell megfoltozni oly módon, hogy hozzon létre egy 
sguashfs-képfájlt, és a Linux rendszermag beállításaiba 

a sguashfs támogatását is bele kell foglalni. Az elért ered- 
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mény bőven megéri a befektetett munkát: az újrafordítás 
után mintegy 500K-val több szabad helyet kapunk az erede- 
ti cramfs fájlrendszerhez képest. 


A vezeték nélküli elosztórendszer 

A normál WR1T54G egy vezeték nélküli hozzáférési 

pont (AP), ami azt jelenti, hogy képes más vezeték nél- 
küli ügyfelekkel való kapcsolattartásra, azonban más 
vezeték nélküli hozzáférési pontokkal már nem. A wl 
paranccsal elérhető, hogy a Wireless Distribution System 
(WDS, vezeték nélküli elosztórendszer) segítségével más 
hozzáférési pontokhoz kapcsoljuk, vagy hogy vezeték 
nélküli ügyfélként működtessük. 

A Wireless Distribution System egy olyan IEEE műszaki le- 
írás, amely lehetővé teszi, hogy egy nagy távolságokat át- 
hidaló hálózatban összekapcsoljuk a vezeték nélküli hozzá- 
férési pontokat. Habár ezért némi teljesítményveszteséggel 
kell fizetnünk, a kapott kiterjesztett vezeték nélküli hálózat 
sokkal nagyobb hatótávolságú, mint amilyen a külön álló 
hozzáférési pontok alkalmazásával elérhető lenne. 

Két hozzáférési pont WDS-sel történő összekapcsolásához 
ismernünk kell a készülékek egyedi MAC-azonosítótt. 
Jelentkezzünk be az egyes készülékekre, és futtassuk a w! 
wds [MAC-cím] parancsot megadva a másik készülék adatát. 
Ennek hatására egy új, wds0.2 eszköz jelenik meg a készü- 
lékeken, amelyhez most már IP-cím rendelhető. Ha elvégez- 
tük az IP-címek hozzárendelését és a két készülék közti út- 
vonalválasztást is beállítottuk, akkor a ping paranccsal el- 
lenőrizhetjük is az összeköttetést a két készülék között. 
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Minden egyes WDS-kapcsolat a hálózaton belüli adatfor- 
galom megkettőződésével jár. Mivel a 802.11g protokoll 
félduplex jellegű, ez a hálózati átvitel feleződését jelenti. 
Amennyiben a hozzáférési pontok 54MB/s sebességen mű- 
ködnek, ez nem nagy áldozat, amíg a kapcsolatok száma 


három vagy annál kevesebb. 


Ügyfél-módú összeköttetés 

Az összekapcsolás egyszerűbb formája az egyik készülék 
ügyfélként való beállítása és egy hozzáférési ponthoz való 
csatlakoztatása. Ezt Ethernet hídnak hívják és számos esz- 
közt kifejezetten ezzel a céllal működtetnek. 

Az ügyfélmódot a Linux rendszermagban kell kiválaszta- 
ni és ezzel a beállítással kell a rendszermagot lefordítani. 
Ha ezzel készen vagyunk, a rendszermagot a Broadcom 
egy bináris moduljával kell összeépíteni, amely tartalmaz- 
za mind az AP-, mint az ügyfélmódot. A w! ap 0 ügyfél- 
módba kapcsolja a készüléket, míg a wIl join [SSID] egy 
másik hozzáférési ponthoz köti. Ha az ügyfélen az útvo- 
nalválasztás alapértelmezett átjárójának a a hozzáférési 
pont IP-címét adjuk meg, az ügyfél azonnal a hozzáférési 
pontra irányítja az adatokat és a híd aktívvá válik. Löbb 
AP-ügyfél pár is beállítható, ami egy másik lehetőséget 
kínál a fent vázolt WDS-módszer mellett. 


A nyílt forráskód hatékonysága 


A Linux megtalálta a helyét a szuperszámítógépektől 
a beágyazott rendszerekig minden területen, így 
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a Linksys eszközökben is. A Linuxra történő átállás a ki- 
élezett versenyt folytató piaci szereplőkkel szemben tá- 
masztott nagy teljesítmény és alacsony költségigény ered- 
ménye. Sok hasonló vezeték nélküli útvonalválasztó, így 
a Belkin F5D7230-4, a Buffalotech WBR-G54 és az ASUS 
WL-3009 és WL-5009 használ Linuxot a firmware-jében, 
és a lista napról napra bővül. Sajnos egyik cég sem tesz 
eleget a GPL követelményeinek, és nem szabadítja fel 

a forráskódot. A jogi kifogások mellett ezek a termékek 
lehetőségeikben és szolgáltatásaikban is rövid időn belül 
messze le fognak maradni a Linksys nyílt forrású termé- 
kei mögött. A Linksys firmware-csomagjai naponta jelen- 
nek meg meglepő új lehetőségekkel. Az írásom idején 
léteznek a Linksys WR1I54G-hez olyan firmware- 
fordítások, amelyek támogatják a VPN-eket, teljesítmény- 
szabályozást, antenna-kiválasztást, ügyfél- és WDS- 
módot, sávszélesség-felügyeletet és még rengeteg min- 
dent, amely különféle forrásokból érhető el. A világháló 
és a nyílt forráskód összekapcsolásával, otthon vagy kis 
irodákban alkalmazható útvonalválasztóból hatékony 
sokfunkciós eszköz hozható létre. 

Figyelmeztetés: kísérleti firmware használatával tönk- 
elveszíthetjük. Ha alkalmi felhasználók vagyunk és csak 
otthoni vagy irodai vezeték nélküli hozzáférésre van 
szükségünk, jobb, ha nem kísérletezünk a leírtakkal, 
hanem ehelyett a Linksys gyári firmware-jét használjuk. 
Ha viszont hajlandóak vagyunk még a készülékünket 

is kockára tenni egy kis kísérletezésért, sokkal többet 
kihozhatunk a dobozból, mint amit a csomagolásán lévő 
leírásban olvashatunk - köszönet érte a Linuxnak és 

a nyílt forrású fejlesztésnek. 


Linux Journal 2004. augusztus, 124. szám 
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több mint 20 éve vállalkozó és szoftverfej- 
lesztő. Kaliforniából egy évtizede kötözött 
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két gyermeke és a Muppet Show svéd 
szakács szerepének gyakorlása közt. 
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Hálózatkezelés NSA Security-Enhanced Linux alatt 


Egy gyakorlati példa segítségével küzdjük le az SELinux bonyolultsága miatti félel- 
meinket, és egyszerűbb kiszolgálóinkat Is vértezzük fel SELInux alapú védelemmel. 


sa rásomban áttekintem, az SELinux segítségével hogyan 
hi növelhető a hálózati rendszerek biztonsága, valamint 
ismertetem hálózati vonatkozású védelmi vezérlőinek 
felépítését és megvalósítását. Ezután átveszünk egy az 
SELinux házirendjének egy egyszerű hálózati alkalmazás 
zárolására való használatát szemléltető példát. 


Az SELinux szerepeinek, típusainak és tartományainak 
áttekintése 

Az SELinux erőteljes általános védelmet nyújt a hálózati 
rendszereknek. Lehetővé teszi, hogy a rendszereket , szűkre 
szabva" a szolgáltatásoknak csak a működésükhöz feltétle- 
nül szükséges jogosultságokat adjuk meg. A lehető legkeve- 
sebb jogosultság alapelvének ilyen jellegű megvalósításával 
meg lehet előzni a biztonsági határok hibás vagy rosszindu- 
latú kód, vagy hibát vétő vagy rosszakaratú felhasználó 
miatt előforduló átlépését. 

Egy külső személyek számára szolgáltatásokat nyújtó 
webkiszolgálót például számos módon lehet védeni: 

e Szükségtelen szolgáltatások letiltása 

e A kiszolgáló program chroot börtönben (jail) való futtatása 
e . Helyi csomagszűrés iptables segítségével 

e —  Jogosultságkezelés sudo segítségével 

e — Beállító fájlok zárolása 


A fentiekkel több réteggel érjük el a biztonság növelését, tu- 
lajdonképpen a mélybe nyúló védelem alapelvét követjük. 
Az SELinux a rendszert egy további biztonsági réteggel bő- 
víti, a kötelező hozzáférés-vezérléssel (mandatory access 
control, MAC). A normál SELinux a MAC-et típusszabályok- 
kal (type enforcement, TE) és szerep alapú hozzáférés-vezér- 
léssel (role-based access control, RBAC) valósítja meg, mind- 
ezt egy központi kezelésű biztonsági házirend vezérli, 
melynek betartatásáról a rendszermag gondoskodik. A ha- 
gyományos UNIX biztonságtól eltérően a normál felhasz- 
nálók semmilyen ellenőrzési jogot nem kapnak az SELinux 
biztonsági házirendjére (erre utal a kötelező jelző), míg 

a rendszergazda, a root feladatköre több, egymástól elkülö- 
nülő felügyeleti szerepre is felosztható, amit a feladatok és 
a felelősség szétosztásának nevezünk. 

A hagyományos, önkényes hozzáférés-vezérlést (discretionary 
access control, DAC) a TE modell megszigorítja, ugyanis az 
operációs rendszer egyes objektumaihoz - folyamatokhoz, 
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fájlokhoz és hálózati erőforrásokhoz - típusokat rendel, 
majd pontosan körülírja a közöttük folyó párbeszédekre vo- 
natkozó szabályokat. (Egy folyamat típusát általában tarto- 
mánynak nevezik.) Mindezekkel az eszközökkel kifinomult 
hozzáférés-vezérlés valósítható meg, és a lehető legkevesebb 
jogosultság elve az operációs rendszer általános értelemben 
vett megerősítésén túl is messze kiterjeszthető. 


Az SELinux hálózati hozzáférés-vezérlési alrendszere 

Az SELinux a 2.6-os rendszermag LSM (Linux Security 
Modules, Linux biztonsági modulok) és Netfilter API-jaira 
épül. Az LSM és a Netfilter egyaránt egy a rendszermag 
stratégiai pontjain elhelyezett csatlakozási pontokból, ,kam- 
pókból" álló hozzáférés-vezérlési keretrendszer. A rendszer- 
magon belüli adatáramlások a csatlakozási pontokon ke- 
resztül a biztonsági modulok, például az SELinux felé irá- 
nyulnak, ezek elvégzik a hozzáférés-vezérlési számításokat, 
majd közlik az eredményt a csatlakozási ponttal. A csatlako- 
zási pont a biztonsági modul utasítása alapján vagy enge- 
délyezi az adatáramlást, vagy megtiltja azt. 

Az SELinux egyik fontos tervezési alapelve, hogy az operá- 
ciós rendszer objektumainak szintjén ellenőrzi a hozzáfé- 
rést. Ahelyett, hogy egy biztonsági figyelő egyszerűen csak 
megmondaná, adott program adott kapcsolókkal és átadott 
értékekkel elindíthat-e egy rendszerhívást vagy sem, az 
SELinux a program futása során annak teljes biztonsági 
környezetét átlátja, továbbá hozzáfér az elérni kívánt objek- 
tum és a végrehajtani kívánt művelet biztonsági címkéjéhez 
is. A rendszergazda által futtatott Is parancs például telje- 
sen más, mint a normál felhasználók által használt. 

Egy SELinux engedély általános formátuma a következő: 

e művelet (forrás környezet) 

e (cél környezet) : (cél objektumosztályok) 

e engedélyek 


Egy példa az SELinux házirendjéből: 

allow bluetooth t self:socket listen; 

A fentiek értelmében a bluetooth t tartomány hallgatózá- 
si (listen) engedélyt kap a saját biztonsági környezetével 


(kontextusával) felcímkézett foglalatokhoz (socket). Egy 
a bluetooth t tartományban futó folyamat tehát egy általa 
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birtokolt foglalaton jogosult a listen() hívás alkalmazására. 
A self (önmaga) csak egy egyszerű jelölés a cél környezet 
egyenlővé tételére a forrás környezettel. A foglalatokkal 
kapcsolatos házirendben gyakran láthatunk ilyen parancso- 
kat, ugyanis a foglalatok általában a létrehozó folyamattal 
azonos biztonsági környezet címkét kapnak. 


A hálózati objektumok címkézése 
SELinux alatt az objektumok biztonsági címkéje a követke- 
ző formátumot követi: 


felhasználó: szerep:típus 
Például: 
root:staff r:staff t 


Ez egy olyan folyamat biztonsági környezete, amelyet 
a staff. r szerepen keresztül, a staff. t tattományban 
a root futtat. A 80-as kapuhoz tartozó címke a következő: 


system u:object r:http port t 


A system u felhasználó és az object r szerep a rendszer- 
objektumok esetében alapértelmezett. Semmi értelme nem 
volna egy kapuhoz valódi felhasználónevet vagy szerepet 
rendelni, hiszen senki sem birtokolja, és nem kezdeményez 
az SELinux elbírálását igénylő műveleteket sem. 


Foglalatok 

A foglalatok címkézése a hozzájuk tartozó fájlleíró (i-node) 
alapján történik. Egy foglalat lehet általános, vagy tartozhat 
az alábbi foglalat alosztályok valamelyikébe: 

e . [NIX folyam (UNIX stream) 

e  [INIX datagram 

e ICP 

e LDP 

e . Nyers (ICMP vagy egyéb nem TICP/UDP) (Raw) 

e — Netlink család 

e Csomag (Packet) 


e — Kulcs (pfkeyv2) (Key) 


A biztonsági házirendben a foglalatok alosztályait is meg 
lehet különböztetni egymástól, így magas fokú rugalmassá- 
got lehet elérni, és kifinomult vezérlést lehet megvalósítani 
a különféle hálózati protokollok felett: 


allow Ipd t printer port t:tcp socket name bind; 


A szabály értelmében csak az Ipd. t tartományban létreho- 
zott ICP foglalatok kötődhetnek a printer. port t típusú 
kapukhoz. 


Kapuk 

Az IPv4 és az IPv6 kapuk címkézése implicit módon, a rend- 
szermagon belül, a házirend által megszabottak szerint tör- 
ténik. A kaputípusok címkézésének formátuma a következő: 
portcon protokoll f( kapuszám ] kaputartomány 3 
környezet 
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Az alábbi szabály a szabványos nyomtatókapu címkézésé- 
hez adja meg a biztonsági környezetet: 


portcon tcp 515 system u:object r:printer port t 


Hálózati csatolók 

Minden hálózati csatoló (network interface, netif) a házirend- 
ben megadottak szerint kap biztonsági környezetcímkét. 

A hálózati csatolók címkézése a következőképpen történik: 


netifcon csatoló környezet 
alapértelmezett üzenet környezet 


Az alapértelmezett üzenet környezet érték a csatolón 
keresztül beérkező üzenetek címkézésére szolgálna, ám 
jelenleg használaton kívül van. 

Két példa házirend netif címkéjére: 


netifcon ethO0 system u:object r:netif intranet t 
MET] 
netifcon ethi system u:object r:netif extranet t 


SET zs d 


Csomópontok 

SELinux alatt a csomópont egy IPv4 vagy IPv6 címet vagy 
hálózati maszkot jelent. Lehetővé teszi állomás- és hálózat- 
címek házirenden keresztül való biztonsági címkézését. 


A csomópontok címkézése a következő formátumot követi: 
nodecon cím maszk környezet 
Példa helyi cím címkézésére: 


nodecon 127.0.0.1 255.255.255.255 
system u:object r:node lot 
nodecon ::1 
mz Tfff:ffFff:FffFf:FfFTFfFT:FfFTFfF:fFFfF:FfFFfF:fFFf 
system u:object r:node lot 


Hálózati csatlakozási pontok és engedélyek 

A hozzáférés-vezérlési csatlakozási pontokat minden foglala- 
tokkal kapcsolatos rendszerhíváshoz megvalósították, így 
minden foglalat alapú hálózati protokoll működését ellenőriz- 
ni lehet SELinux házirenddel. A csatlakozási pontok némelyi- 
ke csupán a rendtartást szolgálja, ám nagyobb részük egy 
vagy több hozzáférés-vezérlési engedély ellenőrzését végzi. 
Általános foglalatvezérlő meglehetősen sok van, ezért 

a csatlakozási pontok, a foglalatokra vonatkozó rendszerhí- 
vások és az engedélyek közötti kapcsolatokat az 1. táblázat- 
ban foglaltam össze. 

Belül a socketO rendszerhívás két csatlakozási pontra osz- 
lik. Az selinux socket create csatlakozási pont annak el- 
lenőrzésére alkalmas, hogy a folyamat létrehozhatja-e a meg- 
adott típusú foglalatot. Az selinux socket post create 
felügyeleti csatlakozási pont a foglalathoz rendelt fájlleíró 
biztonsági címkéjének megadását és foglalattípusának meg- 
határozását teszi lehetővé. 

Az SELinux engedélyek a rendszerhívások és az egyéb 
műveletek biztonsági szemszögből való elvonatkoztatá- 
sához is hozzájárulnak. Vegyük észre például, hogy 


1. táblázat A csatlakozási pontok, a foglalatokra vonatkozó rendszerhívások és az engedélyek kapcsolatai 


Csatlakozási pont 
selinux socket. create socket 
socket 


bind 


selinux socket post. create 
selinux socket bind 

selinux socket connect connect 
selinux socket listen listen 
selinux socket accept accept 
selinux socket sendmsg sendmsg, 
selinux socket recvmsg recvmsg, 
selinux socket getsockname getsockname 
selinux socket getpeername getpeername 
selinux socket setsockopt setsockopt 
selinux socket getsockopt getsockopt 


selinux socket shutdown shutdown 


Rendszerhívás 


send, sendto 


recv, recvfrom 


SELinux engedély 

create (létrehozás) 

ME a. 

bind (kötődés) 

connect (kapcsolódás) 

listen (hallgatózás) 

accept (fogadás) 

write (írás) 

read (olvasás) 

getattr (jellemzők lekérdezése) 
getattr (jellemzők lekérdezése) 
setopt (kapcsolók megadása) 
getopt (beállítások lekérdezése) 


shutdown (leállítás) 


2. táblázat A fájlokra jellemző csatlakozási pontok és engedélyek 


Csatlakozási pont Rendszerhívás 


selinux file ioctl 1octl] 
selinux inode getattr fstat 
selinux inode setattr fchmod, fchown 
fenti 


fcntl, flock 


selinux file fcntil 
selinux file lock 


selinux file permission write, write, read 


a getsockname() és a getpeername() rendszerhíváshoz 
egyaránt a getattr engedély tartozik. Az SELinux ezek biz- 
tonsági szerepét egyenlőnek veszi. Hasonlóan, minden 
sendmsg0) és recvmsgO alapú rendszerhívás biztonságfel- 
ügyeleti szempontból egyszerű írásnak vagy olvasásnak 
számít. Akit a részletek is érdekelnek, a csatlakozási ponto- 
kat megvalósító kódot a 2.6-os rendszermag forrásában, 

a security/selinux/hooks.c fájlban találja. 

Mivel a foglalatok is fájlok, a fájlokra vonatkozó hozzáférés- 
vezérlés egy részét is megöröklik. A 2. táblázat a fájlokra jel- 
lemző, de a foglalatokra is érvényes csatlakozási pontokat 
tartalmazza. 


A UNIX tartományra vonatkozó engedélyek 

Linux alatt a UNIX tartomány foglalatait elvonatkoztatott 
névtérben, a fájlrendszertől függetlenül lehet létrehozni. 
Az elvonatkoztatott névtérben lévő UNIX tartománybéli 
foglalatok közötti adatcserék, illetve ezek irányultságának 
ellenőrzésére további csatlakozási pontokat valósítottak 
meg. Az selinux socket unix stream connect csatlako- 
zási pont a connectto engedély meglétét ellenőrzi, amikor 
egy UNIX tartománybéli foglalat adatfolyam (stream) kap- 
csolatot próbál létesíteni egy másikkal. 
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SELinux engedély 

ioctl 

getattr (jellemzők lekérdezése) 
setattr (jellemzők beállítása) 
lock (zárolás) 

lock (zárolás) 


append, write, read (hozzáfűzés, írás, olvasás) 


Az selinux socket unix may. send csatlakozási pont 

a sendto engedély meglétét követeli meg ahhoz, hogy az 
egyik UNIX tartománybéli foglalat datagramot küldhessen 
egy másiknak. 

A UNIX tartománybéli foglalatok egy további Linux alatti 
szolgáltatása az egyenrangú felek hitelesítése 

a SO PEERCRED - foglalatokra vonatkozó - kapcsolóval. 

A kapcsoló az egyenrangú fél felhasználó-, csoport és folya- 
matazonosítójának lekérdezését eredményezi. SELinux alatt 
egy-egy egyenrangú fél biztonsági környezetét egy új, szin- 
tén foglalatokra vonatkozó művelettel, a SO PEERSEC kap- 
csolóval is megtudhatjuk. A getsockopt (2) hívást ezzel 

a kapcsolóval indítva a selinux socket getpeersec csatla- 
kozási pontra adhatjuk át a vezérlést, mely a felhasználó 
által megadott pufferbe másolja a biztonsági környezetet. 
Ezt a megoldást helyi folyamatok közötti kommunikációra, 
például megnövelt biztonságú adatbusz (Security-Enhanced 
DBUS) megvalósítására használják. 


Netlink vezérlők 

A Netlink foglalatok üzenet alapú felhasználó/rendszermag 
adatcserét tesznek lehetővé. Például a rendszermag irányító- 
táblájának és az IPSec működésének beállítására használhatók. 
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A Netlink adatcsere aszinkron jellegű, az üzenetek küldése 
és fogadása eltérő biztonsági környezetben is lehetséges. 
Netlink csomag továbbításakor a küldő biztonsági engedé- 
lyei egy képességhalmaz formájában a csomag mellé kerül- 
nek, fogadáskor pedig megtörténik az ellenőrzésük. Így le- 
hetővé válik, hogy például a rendszermag forgalomirányító 
kódja ellenőrizze, hogy az irányítótábla frissítését küldő fel- 
használónak valóban van-e joga ilyen frissítés küldésére. 
Az LSM tervezet részeként a képességeket kezelő kódok 

a rendszermagból átkerültek egy biztonsági modulba, így 
az LSM-ek szükség esetén többféle biztonsági modell meg- 
valósítására is alkalmasak. 

Az SELinux modul az selinux netlink send csatlakozási 
pontot használja arra, hogy kizárólag a NET ADMIN képességet 
a rendszermag által küldött Netlink csomagokba bemásolja. 
Az selinux netlink recv csatlakozási pont a biztonsági 
szempontból fontos üzenetek fogadásakor jut szerephez. 
Az SELinux ezt a csatlakozási pontot alkalmazza annak el- 
lenőrzésére, hogy a NET. ADMIN képesség másolása a csomag 
elküldésekor megtörtént-e, valamint a küldő folyamat való- 
ban rendelkezett-e ezzel a képességgel. 

Egyre több Netlink család kerül megvalósításra, és az 
SELinux a biztonsági szempontból kritikus Netlink foglala- 
tokhoz alosztályokat ad meg. Így a foglalatok feletti fel- 
ügyelet az egyes Netlink családokra egyedileg állítható be, 
amivel elérhető például az irányítási üzenetek és a rendszer 
naplózási üzeneteinek megkülönböztetése. 

Az SELinux az selinux netlink send csatlakozási pont 
révén annak meghatározására is képes, hogy a Netlink 
foglalatok egyes típusain az üzenetek olvasási vagy írási 
műveletek, majd rendre alkalmazza az n]imsg read vagy 

az n]lmsg write engedélyeket. Ezáltal rendkívül kifinomult 
házirend állítható össze, például adott tartomány számára 
engedélyezni lehet az irányítótábla kiolvasását, miközben 
meg lehet tiltani annak frissítését. 


IPv4 és IPv6 vezérlők 
Az SELinux számos vezérlőt tartalmaz a ICP, az UDP és 


a nyers (raw) foglalat alosztályokhoz. A node bind enge- 
dély szabja meg, hogy egy foglalat kötődhet-e egy meg- 
adott típusú csomóponthoz. Értelemszerűen csak helyi 
IP-címnél érdemes használni, és általa adott démon adott 
IP-címhez való kötődését lehet meggátolni. 

A name bind engedély azt szabja meg, hogy egy foglalat 
kötődhet-e adott típusú kapuhoz. Csak akkor jut szerephez, 
ha a kapu száma a helyi kaputartományon kívülre esik. 

A helyi kaputartomány az, ahonnan a rendszermag a kapu- 
számok önműködő kiosztását végzi (például, amikor egy 
kimenő TICP-kapcsolat forráskapujának számát kiválasztja), 
megadására a net. ipv4.ip. local port range rendszer- 
hívás használható. Egy átlagos rendszeren a tartomány 

a következő: 


$ sysctl] net.ipv4.ip. local port range 
net.ipv4.i1p. local port range — 32768 61000 

A name bind meghívására tehát csak akkor kerül sor, ha 
egy foglalat egy e tartományon kívülre eső kapuhoz kö- 
tődik. Az SELinux az 1024 alatti számú kapuk esetében 
mindig megvizsgálja az engedélyeket, függetlenül a sysctl 
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beállítástól. Mindkét kötődés vonatkozású vezérlő az 

selinux socket bind csatlakozási pontról kerül meghí- 
vásra, mely viszont a bind(2) rendszerhíváson keresztül 

jut a vezérléshez. 

A send msg és a recv msg engedély annak szabályozására 
alkalmas, hogy egy foglalat egy adott típuson vagy kapun 
keresztül küldhet vagy fogadhat-e üzeneteket. 

Számos vezérlő határozza meg, hogy ICP, UDP vagy nyers 
foglalaton keresztül lehet-e megadott típusú netif és csomó- 
pont objektumok felé és felől csomagokat küldeni és fogad- 
ni; ezek a tcp. send, a tcp. recv, az udp. send, az udp. recv, 
a rawip.send és a rawip. recv. 

Mindezeket az üzenet alapú vezérlőket az 

selinux sock rcv. skb csatlakozási pont hívja meg a beér- 
kező üzenetekre, ez ugyanis a hálózati verem első olyan 
pontja, ahol a csomagok egyértelműen hozzárendelhetők 

a fogadó foglalatokhoz. A kimenő csomagok kezeléséhez az 
SELinux bejegyez egy Netfilter csatlakozási pontot, és az ÍP 
rétegben elfogja a csomagokat. A kimenő csomagokhoz csa- 
tolt tulajdonlási adatok ebben a fázisban is megmaradnak. 
A fenti vezérlők annyiban mind protokollfüggetlenek, hogy 
IPv4 és IPv6 protokollokkal egyaránt működnek. 


Hálózati házirend 

Az elmélettel foglalkoztunk eleget, lássunk tehát egy valódi 

SELinux házirendet egy egyszerűbb hálózati alkalmazás- 

hoz. Mivel helyszűkében vagyunk, az igazi hálózatkezelés 

pedig sosem egyszerű, csak egy egyszerű ICP visszhang- 

ügyfél számára fogunk házirendet készíteni. 

Az ügyfél forráskódja a cikkhez tartozó internetes források 

között szereplő weboldalon érhető el. Rövid annyit róla, 

hogy létrehoz egy ICP foglalatot, kapcsolódik a távoli állo- 

más visszhang kapujához, kiír valami szöveget, majd 

visszaolvassa. 

Saját munkaállomásom két Ethernet csatolóval rendelkezik, 

a példában az eth0O egy intranetbe tartozik, és a kiszolgáló, 

melyhez csatlakozok, a 10.3.1.2 IP-címet viseli. 

Amit a biztonsági házirendtől elvárunk: 

e Az ügyfél az operációs rendszernek csak a valóban 
szükséges erőforrásaihoz férjen hozzá. 

e Az ügyfél kommunikációs lehetőségei csak a 10.3.1.0/24 
alhálózatra eső inetd kiszolgálókra és az eth0 csatolóra 
terjedjenek ki. 


Házirend 

Az alábbiakban egy a fentieknek megfelelő, megjegyzések- 
kel ellátott házirend szerepel. Használatához telepíteni kell 
a terjesztésünkhöz készült SELinux házirend forráscsoma- 
gokat, majd legfelső szintű könyvtárába kell lépnünk (saját 
gépemen ez a /etc/selinux/strict/src/policy). 

Hozzuk létre a domains/program/echoclient.te nevű fájlt, 
majd adjuk hozzá az 1. kódrészletben szereplő házirendbe- 
jegyzéseket. 

A net contexts fájlhoz a következő címkemegadásokat kell 
hozzáadni: 


f eth0 címke 
netifcon ethO0 system u:object r:netif intranet t 
system u:object r:unlabeled t 
f A belső hálózat címkézése. 
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1. kódrészlet echocllent.te 


ft Egyszerű visszhangügyfél (echoclient) házirend allow echoclient t sshd t:fd use; 

f a linuxvilágos cikkhez allow echoclient t staff devpts t:chr file í 

f Fájl: domains/program/echoclient.te getattr read write bt; 
f Az echoclient t típus megadása tartományként ft Hálózati beállítások 

type echoclient t, domain; f Ezek a tartomány által igényelt foglalat 


f engedélyek. 
f Az echoclient exec t megadása futtatható típusú ft Érdemes megjegyezni, hogy csak a TCP 


ft fájlként. ft foglalatokra érvényesek. 
type echoclient exec t, file type, exec type; allow echoclient t echoclient t:tcp socket ( 
connect create read shutdown 
f Ez egy makró, ez fogja engedélyezni write jt; 
f a megfelelően címkézett futtatható fájlnak ff Engedélyezzük a programnak, hogy TCP üzeneteket 
f az átlépést az echoclient t tartományba f küldjön a visszhangkapu 
f a staff t tartományból. f felé, illetve ilyeneket fogadjon tőle. 
domain auto trans(staff t, echoclient exec t, f Egy normál házirendben a kapu 
echoclient t) f inetd port t címkét kap, és az inetd által 
f kezelt kapuk csoportjába tartozik. A 
ft Megadjuk, hogy mely szerepek léphetnek be az f net contexts fájlban szereplő házirendet 
f echoclient t f módosítva a szabály 
ft tartományba. f egyetlen kapura is szűkíthető. 
role staff r types echoclient t; allow echoclient t inetd port t:tcp socket ( 
recv msg send msg bt; 
f Ez a makró teszi lehetővé a tartománynak f Az intranetes csatolón keresztül csak a TCP 
f a megosztott fforgalmat engedélyezzük. 
ft könyvtárak használatát. allow echoclient t netif intranet t:netif ( 
uses shlib(echoclient t); tcp. recv tcp. send ht; 


ft Azoknak az engedélyeknek a biztosítása, amelyek f A belső IP-címekkel csak TCP alapú 


f a program futtatásához staff t-ként, SSH-n $ kommunikációt 
ft keresztül való bejelentkezésnél szükségesek, f engedélyezünk. 
f így válik lehetővé a hibakereső és -jelző allow echoclient t node internal t:node í 
f üzenetek kiírása a felhasználó termináljára. tcp. recvtcp. send bt; 
nodecon 10.3.1.0 255.255.255.0 Ezzel a házirend elkészült. Látszólag rengeteg munka volt 
system u:object r:node internal t vele, ám ha már otthonosan mozgunk a különféle házirend- 
fájlok között, és jobban megismertük a szükséges házirend- 
A types/network.te fájlba kerülő sorok: bejegyzések típusait, minden könnyebbé válik. Ekkor már 
az olyan eszközöket is könnyebben tudjuk majd használni, 
f A netif intranet t megadása hálózati mint például az audit2a1 low, amely a napló tiltási üzenetei 
$ csatoló típusként. alapján engedélyező szabályokat hoz létre. A mindennapi 
type netif intranet t, netif type; házirendkészítéshez jobb valamilyen magasabb szintű, grafi- 
kus eszközt használni, jelen esetben azonban a dolgok mű- 
Fájlkörnyezet megadása a futtatható fájl számára egy új, ködésének lépésről lépésre való bemutatása volt a cél. 
file contexts/program/echoclient.fc nevű fájlban: 
Próba 
ft Alapértelmezett fájlkörnyezet a címkézéshez Fordítsuk le és lássuk el címkével a futtatható ügyfél- 
/tmp/echoclient - programot: 


s system u:object r:echoclient exec t 
$ make echoclient 
Fordítsuk le és töltsük be a házirendet: CC echocilient.c -o echoclient 


$ make load $ restorecon /tmp/echoclient 
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Ellenőrizzük a címke helyességét: 


$ getfilecon /tmp/echoclient 
/tmp/echoclient 
s system u:object r:echoclient exec t 


Erre a célra az Is -Z parancsot is használhatjuk. 
Lássuk, működik-e a rendszer. Rootként jelentkezzünk be 
SSH-n keresztül staff r szerepbe, majd: 


$ id -Z 

root:staff r:staff t 

$ /tmp/echoclient 10.3.1.2 
Sending message: "Hello, cliche" 
Received message: "Hello, cliche? 


Működik! 

A házirendet auditallow szabályokkal bővítve azt is fi- 
gyelemmel követhetjük, hogyan folyik az engedélyek 
megadása. 

Ellenőrizzünk is néhány házirendbéli szabályt, vajon való- 
ban működik-e. 


1) Próbáljunk egy az intraneten kívülre eső IP-címmel kap- 
csolatot létesíteni. A címet helyileg irányítsuk, így nem 
fordulhat elő, hogy véletlenül az internet felé küldünk 
el egy csomagot: 


$ ip ro add 196.40.74.92 via 10.3.1.2 dev ethoO0 
$ /tmp/echoclient 196.40.74.92 


A program ICP időtúllépést kap, és csomag küldésekor az 
alábbi, tiltásról értesítő naplóüzenet jön létre: 


avc: denied ( tcp send 3 for pid-10831 
exe-/tmp/echoclient saddr-10.3.1.1 src-32822 
daddr-196.40.74.92 dest-7 netif-etho0 
scontext-root:staff r:echoclient t 
tcontext-system u:object r:node t 
tclass-node 


Mint vártuk, az echoclient t tartomány nem kapott enge- 
délyt arra, hogy ICP csomagot továbbítson /node t/ csomó- 
pontnak (ez az alapértelmezett általános csomópont kör- 
nyezet). 


2) Próbáljunk másik csatolón keresztül kommunikálni. 
A visszhang kiszolgáló IP-címét irányítsuk a hurok 
felületen keresztül, így a csomagok erre kerülnek 
elküldésre: 


$ ip ro add 10.3.1.2 via 127.0.0.2 dev lo 


$ /tmp/echoclient 10.3.1.2 

avc: denied ( tcp send ti for pid-10828 
exe-/tmp/echoclient saddr-10.3.1.1 src-32821 
daddr-10.3.1.2 dest-7 netif-lo 
scontext-root:staff r:echoclient t 
tcontext-system u:object r:netif lot 
tclass-netif 
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Most is helyes eredményt kaptunk. Az echoclient t tarto- 
mány nem kapott engedélyt arra, hogy netif lo t hálóza- 
ti csatolón keresztül továbbítson csomagot. 

Az echoclient program a házirend értelmében rendkívül 
szűkre szabott jogosultságokkal fut. Amit nem engedtünk 
meg kifejezetten, az tilos számára. A programban esetlegesen 
felmerülő hibák, a felhasználó hibázásának vagy rosszindula- 
tának hatása a házirend révén erőteljesen korlátozható. 
Egyszerű példánk alapján világossá válik, hogy SELinux 
házirenddel hogyan lehet elérni a hálózati biztonság terén 
kitűzött célokat. Egy valós környezetben alkalmazott házi- 
rendnek számos különleges lehetőséget kell biztosítania, 
ezekkel a helyszűke és az érthetőség miatt nem foglalkoz- 
tunk, de példaként érdemes az ICMP-üzenetek és a DNS- 
lekérdezések engedélyezését megemlíteni. Mindenkinek 
javaslom a saját terjesztéséhez készült házirendforrások 
tanulmányozását, illetve a grafikus házirendkészítő alkal- 
mazások kipróbálását. 


Jövőbeli fejlesztések 

SELinux alatt valószínűleg meg fog valósulni a címkézett 
hálózatkezelés valamilyen formája. Ennél a megoldásnál 
maga a hálózati forgalom kerül címkézésre - ilyesmire legin- 
kább bizalmas adatokat kezelő katonai és kormányzati rend- 
szerekben láthatunk példát. Az SELinux egy korábbi válto- 
zata IP-beállításokat használt a csomagok címkézésére, ám 
ezt a megoldást kivették belőle, még mielőtt a rendszermag 
fő ágába bekerült volna, ugyanis a szükséges csatlakozási 
pontok túlságosan mélyrehatók voltak. Egy másik megoldás 
lenne az SELinux és az IPSec egybeépítése, és a biztonsági 
társulások (Security Associations, SA) címkézése a csomagok 
helyett. Egy adott SA-n érkező csomagot implicit módon le- 
hetne címkézni az SA környezetével. A korábbi Flask Project 
keretein belül már készült minderre egy prototípus, az itt 
szerzett eredmények kiváló útmutatóként szolgálhatnak. 

Az SELinux szorosabb egybeépítése más hálózatbiztonsági 
összetevőkkel, például a titkosítással vagy a tűzfalakkal, 
további kutatások tárgya. 
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Maradjunk naprakészek terjesztésünk biztonsági 


frissítéseivel 


A kezdő Linux rendszergazdák számára a programok naprakészen tartása az első 
lecke. Jeremy ennek a népszerű frissítő eszközök segítségével való elvégzését 


tárgyalja, kattintásról kattintásra. 


a a Linuxot asztali vagy kiszolgáló környezetben 
meg akarjuk őrizni első számú játékosnak, akkor 
ügyelnünk kell arra, hogy a biztonsági foltok segít- 
ségével naprakészek maradjunk. Hiába tesszük meg a szük- 
séges biztonsági intézkedéseket a hálózat és a vas szintjén, 
ha egyetlen apró rés miatt az egész rendszer sebezhetővé 
válik. Minden felhasználónak, legyen szó akár üzleti, akár 
nonprofit, akár otthoni használatról, tisztában kell lennie 
azzal, rendszerét és alkalmazásait miként frissítheti, és 
rendszeresen meg is kell ezt tennie. 

A rendszer sértetlenségének megőrzéséhez két lépésre van 
szükség: tudni kell, mikor kell frissíteni, és valóban végre is 
kell hajtani a frissítést. Az első feladatot a terjesztéshez tar- 
tozó biztonsági témájú levelezőlista figyelésével teljesíthet- 
jük. A második elvégzésére számos mód kínálkozik, végre- 
hajtásához grafikus és parancssori eszközöket egyaránt 
használhatunk. Néhány terjesztés önműködő frissítő segéd- 
eszközt is tartalmaz, melynek segítségével könnyebben fi- 
gyelemmel követhetjük rendszerünk állapotát. 

Az adott alkalmazás újabb változatának telepítését frissítés- 
nek vagy foltozásnak is nevezhetjük, a két művelet lényege 
ugyanaz. Ugyanakkor arra is érdemes figyelni, hogy a Íris- 
sítés során ne telepítsünk olyan csomagváltozatot, amelyet 
eredetileg nem akartunk feltenni. A csomagok fejlesztői vál- 
tozatai általában külön sorszámsorozatból kapják változat- 
számukat. Ha a változatszám túlságosan különbözik, vizs- 
gáljuk meg, milyen egyéb változatokat tudunk elérni. 
Írásomban a linuxos rendszerek naprakészen tartására hasz- 
nálható eszközök grafikus és parancssori változatával egyaránt 
foglalkozok. Részletesebben a Debian 3.0 (Woody), a Mandrake 
10.0, a SuSE 9.1 és a Fedora Core 2 terjesztésről lesz szó. 





Mikor frissítsünk? 

Honnan tudhatjuk, hogy mikor kell frissítést végeznünk? 

A legjobb módszer az, hogy feliratkozunk a terjesztésünkkel 
kapcsolatos biztonsági értesítők levelezőlistájára. Az inter- 
netes források között az itt tárgyalt terjesztésekre és a megfe- 
lelő biztonsági levelezőlistákra vezető hivatkozások egyaránt 
megtalálhatók. Ezek általában kis forgalmú listák, általuk 

a biztonsági jellegű foltokról vagy frissítésekről értesülhetünk. 
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Általában közvetlen hivatkozásokat is tartalmaznak a frissített 
csomagok letöltéséhez, a csomagok helyességének megőrzé- 
sét pedig MD5 ellenőrző összegekkel segítik. Ennél a mód- 
szernél a csomagokat kézzel kell telepítenünk, és a függősé- 
geket is magunknak kell feloldanunk. A frissítések megjelené- 
séről úgy is értesülhetünk, hogy írunk egy a frissítéseket 
rendszeresen lekérdező parancsfájlt. SuSE 9.1 és Fedora Core 2 
alatt meglévő programjainkat könnyedén, grafikus felületről 
tudjuk frissíteni. Debian és Mandrake alá szintén léteznek jól 
áttekinthető grafikus eszközök, ezeket parancsfájlokkal arra is 
rávehetjük, hogy az éjszaka közepén töltsék le a frissítéseket, 
amelyek telepítését a számunkra kényelmes időpontra tolhat- 
juk el. Muszáj megemlítenem a programok felügyelet nélküli 
frissítésének veszélyeit. Nálam például az Apache webkiszol- 
gáló pontos beállítása komoly munkát jelent. Frissítéskor min- 
dig szembesülök a kérdéssel: szeretném-e felülírni meglévő 
beállító fájljaimat? A legtöbbször a diff segítségével átnézem, 
milyen változtatásokra számíthatok, és a beállító fájl felülírá- 
sát általában nem engedélyezem. Ha létfontosságú alkalma- 
zásokat is futtatunk, mindig fordítsunk kellő gondot a változ- 
tatások rögzítésére, a beállító fájlokról pedig készítsünk biz- 
tonsági mentéseket. 


RPM alapú terjesztések 

Az RPM parancssori eszköz megbízható, kézi módszert kí- 
nál a biztonsági frissítések telepítésére. Az rpm parancsnak 
rengeteg kapcsolója van, ám a csomagok frissítéséhez csu- 

pán a következő utasítást kell kiadnunk: 

f rpm -Uv csomag.rpm 


Az RPM tájl helyi fájl is lehet, de FIP-n vagy HITP-n ke- 
resztül elérhető fájlt is megadhatunk. Ha a biztonsági leve- 
lezési listán közvetlen URL-eket kapunk a frissített csoma- 
gokra, akkor a parancssori frissítés roppant egyszerűvé vá- 
lik. Az rpm parancssori eszközről az RPM webhelyen vagy 
a megfelelő man oldalon találunk további tájékoztatást. 


Debian alapú terjesztések 
A Debian és az egyéb, Debianra épülő terjesztések csomag- 
kezelője a dpokg. Neve a Debian GNU/Linux package 
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a Synaptic Package Manager 
Ale Edit Package Settings Help 
v 
Reload Mark All Upgrades — Apply Properties Search 


key 


Sections : v Package installed Version —— Latest version Size Description 
All 2 TA alexandria 0.3.1-4 

[B libmagma-dev 0 trunk20040913-1 
TB magma 0 trunk20040913-1 
[B python2.2-scipy-core 


(B pytig 


a GNOME application for managint 
Ánátéiyr Kádiő Magma cluster abstraction - devel 
Magma cluster abstraction - tool 
Scientific tools for Python 


Scientific tools for Python 


Amateur Radio (non free) 
Base System 0.3.04-108.1820-1 
Communication siélnelnak ie? 
Communication (non free) 


Converted From RPM by alie 


Apply the following changes? 


This is your last opportunity to look through the list of 
marked changes before they are applied. 


b Tobeinstalled 
b Tobekept back 


Cross Platform 

Cross Platform (contrib) 
Cross Platform (non free) 
Development 
Development (contrib) 
Development (non free) 


Documentation 
Summary 
1 package will be held back and not upgraded 
o 3 new packages will be installed 
Editors v 68 packages will be upgraded 
1913 kB of extra space will be used 
26.4 MB have to be downloaded 


Documentation (contrib) show Details 


Docurmentation (non free) 


Editors (non free) 
Electronics 
Electronics (non free) Download package files only 
Email 

Email (contrib) 

Email (non free) 

Embedded Devices 

GNOME Desktop Erwironrne 

Games and Amusement 

Games and Amusement (cc 


Games and Amusement (mi, 





a [d 
15878 packages listed, 1604 installed, 0 broken. 71 to installjupgrade, 0 to remove; 1913 kB will be used 


1. ábra A módosítandó alkalmazások a Synaptic listájában 


manager, Debian GNU/Linux csomagkezelő kifejezésből szár- 
mazik. A dpkg GYK szerint a név mára elveszítette jelentő- 
ségét, hiszen a dpkg-t nem Debian rendszerek is használják, 
sőt, a Linuxtól eltérő operációs rendszerek alá is létezik. Ez 
a csomagkezelő lényegében aládolgozik például a APT-nek 
(Advanced Packaging Tool, fejlett csomagkezelő eszköz) és 

a grafikus eszközöknek, például a Synapticnek. Az RPM- 
hez hasonlóan a dpkg is milliónyi parancssori kapcsolót is- 
mer, ám mi most csak a frissítésre használhatóval foglalko- 
zunk, amelynek alkalmazásakor a kiadandó parancs a kö- 
vetkezőképpen fest: 

ff dpkg -i csomag.deb 


A -i kapcsoló a csomag telepítésére utasítja a dpkg-t. Ha 

a csomagból korábbi változat is telepítve van, a dpkg először 
eltávolítja azt, majd felteszi az újabb változatot. Az rpm-től 
eltérően a dpkg-nak a csomag telepítés előtti letöltéséhez 

a wget-re vagy curl-re is szüksége van. 


Debian 3.0 (Woody) 


Debian alatt csomagkezelő feladataink túlnyomó részét va- 
lószínűleg az APT segítségével fogjuk elvégezni. Az APT 
egy listát vezet az elérhető csomagokat tároló forrásokról. 
Ha egy forrás listájában újabb csomagváltozat szerepel, ak- 
kor az APT letölti a csomagot, majd átadja a vezérlést 

a dpkg-nek. Először ellenőrizzük, hogy a biztonsági frissíté- 
sek forrása szerepel-e a sources.conf fájlban. A fájlban a kö- 
vetkező sornak kell szerepelnie: 

deb http://security.debtian.org/ stable/updates main 


A stable szó helyett lehet, hogy a woody szerepel - teljesen 
mindegy. A sources.conf fájl átnézése-átírása után frissíte- 
nünk kell a rendelkezésre álló csomagok listáját. A frissítés 
és a foltozás végrehajtásához az apt-get parancsot kétszer 
kell kiadnunk: 

f apt-get update 

f apt-get upgrade 


Ekkor csak azoknak a csomagoknak a frissítésére kerül sor, 
amelyek más csomagok módosítását nem igénylik. Ha 
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Synaptic Package Manager 


MKE TET EG 


close this dialog after the changes have been applied successfully 


X close 


2. ábra A Synaptic az összes frissítés telepítése után 


a függőségekkel is rendelkező csomagokat is frissíteni akar- 
juk, a következő parancsokat kell kiadnunk: 

f apt-get update 

f apt-get -u dist-upgrade 


A -u kapcsoló segítségével pontosan láthatjuk, hogy mely 
csomagok kerülnek frissítésre, újonnan telepítésre vagy eltá- 
volításra. A fenti parancsokat crontab segítségével is futtat- 
hatjuk, valamint arra is rávehetjük gépünket, hogy mindig 
töltse le a legújabb csomagokat, de ne telepítse őket. A 
crontab fájlba az alábbihoz hasonló parancsot kell beírnunk: 
(apt-get update €8£ apt-get -dy upgrade) 

5] mail -s " hostname frissítés" root 


A parancs letölti a legújabb csomagok listáját, és ha ez sike- 
res, akkor letölti a frissítést igénylő csomagokat is. Az ered- 
ményről elektronikus levélben tájékoztatja a root felhaszná- 
lót. Szükség szerint használjuk saját felhasználónevünket 
vagy levélcímünket. Ha értesítő levelet kaptunk a frissíté- 
sekről, a következő parancsot kell kiadnunk: 

f apt-get upgrade 


Ekkor megtörténik a korábban letöltött csomagok telepítése, 
melynek folyamatát konzolról vagy terminálról tudjuk figye- 
lemmel kísérni. Bizonyos csomagok telepítésekor további be- 
avatkozásra is szükség lehet, ezért érdemes lehet tartózkodni 
a teljes mértékben automatizált módszer használatától. 

A grafikus oldalt szemlélve a Debiant használók számára 

a Synaptic teljes értékű felületet biztosít a dpkg-hoz. 

A Synaptic futtatásához ablakkezelőnk Debian menüjéből az 
AppsSystemsSynaptic Package Manager (Alkalmazások; 
Rendszer Synaptic csomagkezelő) parancsot kell választanunk. 
A Synaptic működése sokban hasonlít az APT-éhez. Ha frissí- 
teni szeretnénk a rendelkezésre álló csomagok listáját, kattint- 
sunk az ablak bal felső részén található Reload ( Újratöltés) 
gombra. Egy ablakban megjelenik a frissített csomaglista tar- 
talma. Amikor a Synaptic végzett a csomaglisták letöltésével, 
az összes rendelkezésre álló frissítést megtekinthetjük. A fris- 
sítést igénylő csomagokat egy zöld négyzet és egy felfelé mu- 
tató nyíl jelzi. Az újonnan elérhető csomagoknál a négyzet- 
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HT! sra 


(s Normal information 
C Maximum information 


cdrecord-2.01-0.a28.2.100mdk 
cups-1.1.20-5.1.100mdk 
cups-common-1.1.20-5.1.100mdk 
cups-drivers-1.1-138.2.100mdk 
dhcp-client-3.0-1.rc14.0.1.100mdk 
dhcp-common-3.0-1.rc14.0.1.100mdk 
foomatic-db-3.0.1-0.20040828.1.1.100m [I 
foomatic-db-engine-3.0.1-0.20040828.1.[] 
foomatic-filters- 3.0.1-0.20040828.1.1.101L] 
ftp-client-krb5-1.3-6.3.100mdk 0 
ghostscript-7.07-19.2.100mdk a 
gtk4-2.0-2.2.4-10.1.100mdk [1 
imlib-1.9.14-8.1.100mdk 0 
kdebase-common-3.2-79.2.100mdk 0 
kdebase-kdeprintfax- 3.2-79.2.100mdk. [J 
kdebase-kdm-3.2-79.2.100mdk d 


Selected size: 0 MB 


YaST Online Update (YOU) is 

the easy way to get all 
recommended patches and 
security fixes from a SuSE 
update server. 


[64 Welcome to YaST Online Update 


- System Information 





There was no update executed up to now. 
If Manually Select Product: SUSE LINUX 
Patches is checked, all 
available patches will be 
shown from which to select 
the patches to install. 

If Reload All Patches from 
Server is checked, all 
patches will be fetched from 
the server even when they 
already are locally available 
from a previous download. 


Version: 9.1 
Base Architecture : 1386 








- Update Configuration 
Installation source 
/ USA: California, Los Angeles v 


Location 





"ftp :[fmirrors.usc.edujpubálinux;distributionsísuse/ 





After clicking New Server, 
select a local installation 
source instead of an FTP or 
HTTP server or select 
another FTP or HTTP server. 
dick Edit Server to edit the 
location of the selected 
server. 








New Server... Edit Server...) 
x Manually Select Patches 
. ) Reload All Patches from Server 








, . Configure Fully Automatic Update... 








Abort j 








. dickina Confiaure Fullv iv 








4. ábra A YaS12 Online Update tükörválasztó folyamata 

















Acrobat Reader for PDF Files 














YasST Online Update Patch 
tat CT terdre pia CTG 
hd A data compresuan Ibrary 
ká A áhrary for dovekoing appicatons with graptúcal usar inter 
há A pnuieged hatpar tor utmp ard wonp update 
hd A Tazt Fikk Ero asár anú Pagac Sindar tú Mara 
há Carwarts ASCI Text ta Postscnipt 
há Defadt S45E Lnux Entorpresa Server Bootsalash Thoma 
há KDE bíása $hranec 
ká Uray for Creation út Graphicad Uar ittartacas 
há Library for tha Portabia Matmork Graphúcs Farnát 

Ef Miinott (nnnandar 








show Patch Category: Installable Patches 





Patch Description 








acroread - Acrobat Reader for PDF Files (el ami ] lap) 








A buffer överflow and a shell meta character problem within the Description I Technical Data ] Dependencies T Versions j 
acrobat reader has been fixed, which allowed attackers to - 
execute arbitrary commands as the user viewing a specially 


crafted document. 








! acroread - Acrobat Reader for PDF Files 








Total Download Size: / 90.8 MB 






































. Name ! Disk Usage I / Used [Free (Total I 
/data3 IWT  ]179s 9.61 GB 46.61 GB 56.22 GB 
! KT] 5961.41GB 26.70GB 28.11 GB 




















j Cancel 1! Accept 





5. ábra A YaS12 Online Update listája az elérhető csomagfrissítésekről 


ben egy sárga csillag látható. A már telepített csomagoknál 
a négyzet zöld, a még nem telepítetteknél pedig fehér színű. 


www.linuxvilag.hu 


Ha az összes csomagífrissítést le szeretnénk tölteni és fel 
szeretnénk telepíteni, akkor kattintsunk az Apply (Alkal- 
maz) gombra. Az ezután megjelenő ablakból megtudhatjuk, 
hogy mely csomagok kerülnek frissítésre, telepítésre, 
visszatartásra vagy eltávolításra (1. ábra). A visszatartott cso- 
magok esetében további, részletesebben meg nem adott 
függőségekkel kell számolni. Ha rákattintunk az Apply 
(Alkalmaz) gombra, megkezdődik a frissítések letöltése. 

A letöltés után a frissítések telepítését egy terminálszerű 
szövegterületen követhetjük, az esetleges kérdésekre is itt 
adhatunk választ. Ha végeztünk, kattintsunk a Close 
(Bezár) gombra. (2. ábra) 


Mandrake 10.0 


A Mandrake 10.0 telepítésekor az első bejelentkezés előtti 
záró lépések egyike a fontosabb frissítések lekérdezése. Ha 
nulláról indulva telepítjük a terjesztést, akkor mindenkép- 
pen szakítsunk időt erre a műveletre. Mit tegyünk azon- 
ban, ha Mandrake rendszerünk már telepítve van, és be 
kellene foltoznunk egy biztonsági rést? 

A Mandrake 10.0 használóinak egy csinos, grafikus felületű 
csomagkezelő alkalmazás áll rendelkezésére, ez az 
rpmdrake. A KDE csillag menüjére kattintva, majd 

a System ConfigurationPackaging: Mandrake Update 
(Rendszer; Beállítások: Csomagkezelés: Mandrake frissítés) pa- 
rancsot választva indíthatjuk el, de a parancssorból roct fel- 
használóként az rpmdrake parancsot is kiadhatjuk. Válaszol- 
juk meg a felbukkanó kérdéseket, és máris megjelenik a biz- 
tonsági okból frissítést igénylő csomagok listája. (3. ábra) Ha 
mindegyiket frissíteni szeretnénk, kattintsunk az All (Mind) 
sorban található négyzetre, majd az Install (Telepít) gombra 
— aztán bontsunk egy sört, és dőljünk hátra. Az összes fÍrissí- 
tés letöltése és telepítése után párbeszédpanel értesít a mű- 
velet sikeres elvégzéséről. Ilyen egyszerű az egész. 

A parancssoros urpmi csomag nálam a Mandrake 10.0 alap- 
elemeként települt. Az urpmi működése sokban hasonlít az 
APT-éhez, és szintén lehetővé teszi több forrás használatát 
a csomagok írissítésére. A forrás lehet CD-lemez, helyi 
RPM könyvtár, vagy FIP vagy HITP alapú internetes erő- 
forrás. A biztonsági javítások telepítéséhez az alábbihoz ha- 
sonló parancsot kell futtatnunk: 

ff urpmi.addmedia -update updates 

s ftp: //pelda . com/Mandrake10.0/RPMS 

Swith ../base/hdlist.cz 


Ezzel egy FIP-tükör biztonsági fírissítéseit adhatjuk hozzá 
a források listájához. lermészetesen az ftp:// URL-t egy 
valós hely címével kell helyettesítenünk. Az Easy urpmi 
weboldalról könnyen átlátható, webes felületről választhat- 
juk ki a hozzánk legközelebb eső tükörhelyet, gépünk típu- 
sát és azt, hogy mely forráskészletekből kívánjuk letölteni 

a frissítéseket. 

Ha le szeretnénk tölteni az elérhető csomagok listáját, majd 
telepíteni szeretnénk az összes csomagífrissítést, a követke- 
ző két parancsot kell kiadnunk: 

f urpmi.update -a 

f urpmi -—auto-select 


Ezután megkezdhetjük a frissített csomagok és a függősé- 
gek miatt szükségesnek ítélt csomagok telepítését. 
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Up2date - Package List 


2.6.0-7 
2.10.04 
2.01.1-0.FC2. 2.01-0.a27.3 1386 0kB 
2.01.1-0.FC2. 2.01-0.a27.3 í386 0kB 


nin ffocAuth 3A. 3. — 8. LE -O.4N. 


915 sat] 
update 


2.6.04 1386 OKB 
2.10.0-2 1386 0kB update 
update / 


Package Information 


Total size of selected packages to download: 0 kB 





6. ábra Az Up2date listája a rendelkezésre álló csomagokról 


915E 9.1 

A SuSE 9.1 hasonló módszert kínál a frissítések telepítésére, 
melyben a YaS1T2 Online Update (YOU) grafikus eszköz 
segít bennünket. A SuSE ikonra, majd a SystemYaST 
(RendszerYaST) parancsra kattintva indíthatjuk el. Írjuk be 
a root jelszavát, majd kattintsunk a Software (Szoftver) és az 
Online Update (Online frissítés) parancsra. Válasszuk ki 

a telepítési forrást, vagy adjunk hozzá kézzel egy új kiszol- 
gálót. (4. ábra) A YOU-t úgy is beállíthatjuk, hogy minden 
nap megadott időpontban önműködően töltse le és/vagy te- 
lepítse a frissítéseket. A Next (Iovább) gombra kattintva le- 
tölthetjük azokat az adatokat, amelyek alapján felmérhető 
a frissítést igénylő csomagok köre. A lista frissítése után 
megkapjuk a csomagok listáját, a foltok leírását és a lemez- 
hely-használattal kapcsolatos adatokat. (5. ábra) A foltok lis- 
tájában vörös vonalak jelzik a biztonsági frissítéseket, kék 
vonalak az ajánlott frissítéseket és feketék az elhagyhatókat. 
A rendszerírissítést az Accept (Elfogad) gombbal indíthatjuk 
el. Ha a frissítés befejeződött, kattintsunk a Finish (Befejez) 
gombra, ezt követően még sor kerül néhány rendszerszol- 
gáltatás beállítására. A YOU mellett, ha akarjuk, a parancs- 
sorból az rpm parancsot is használhatjuk. 


Fedora Core 2 

A Red Hat frissítő ügynöke, az up2date számos Red Hat ter- 
jesztésben szerepelt, és a Fedora Core 2-ben is megtalálható. 
Ha Fedora Core 2 alatt le szeretnénk kérdezni az elérhető fris- 
sítéseket, akkor kattintsunk az egér jobb gombjával a rend- 
szertálcán található piros felkiáltójelre, majd válasszuk 

a Check for updates (Frissítések lekérdezése) parancsot. A leg- 
újabb frissítések letöltését és telepítését a piros felkiáltójelre 
az egér jobb gombjával kattintva és a Launch up2date 
(up2date indítása) parancsot választva indíthatjuk el. Adjuk 
meg az alapbeállításokat. Az up2date első futtatásakor 

a program megkérdezi, hogy telepíteni akarjuk-e a Red Hat 
GPG kulcsaláírását. Én a saját gépemen igennel válaszoltam. 
A Channels (Csatornák) menüben két csatornára vagy 
frissítésforrásra iratkozhatunk fel, ezek a fedora-core-2 és az 
updates-released-fc2. Az up2date csatornái hasonlók az APT 
vagy az urpmi forrásaihoz. Következőként megadhatjuk az 
átlépni kívánt csomagokat. Nálam az eleve megjelenő cso- 
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Up2date - Finish Page 


All Finished 





The Red Hat Update Agent has finished installing 
the following packages successfully: 


(GConf2-2.6.0-7 
ORBIit2-2.10.0-4 
cdda2wawv-2.01.1-0.FC2.1 
cdrecord-2.01.1-0.FC2.1 
cups-1.1.20-11.3 
cups-ibs-1.1.20-11.3 
dhclient-3.0.1rc14-1 
dvd--rw-tools-5.21.4.10.8-1.FC2.1 
fam-2.6.10-9.FC2 
finger-0.17-24 
foomatic-3.0.1-3.1 
ftp-0.17-21 
gaim-1.0.0-0.FC2 
gdk-pixbuf-0.22.0-11.3.5 
gimp-2.0.4-0.fc2.1 
gnome-applets-2.6.2.1-1 
gnome-session-2.6.0-4 

















7. ábra Az Up2date végzett a letöltéssel és a telepítéssel 


mag egy rendszermagírissítés volt. A Forward (Iovább) 
gombra kattintva megkapjuk az elérhető frissítések listáját. 
(6. ábra) Ha az összes frissítést telepíteni akarjuk, akkor 
jelöljük be a Select all packages (Minden csomag kijelölése) 
jelölőnégyzetet. 

Újra a Forward gombra kattintva elindíthatjuk a csomagok 
letöltését. Ezen a ponton megismételném a sörözéssel és 

a pihenéssel kapcsolatos ajánlatomat. Ha a letöltés befejező- 
dött, újfent kattintsunk a Forward gombra, ezzel elindítjuk 
a telepítést. Ha a telepítés is véget ért, a program megjelení- 
ti, hogy pontosan mely csomagokat és milyen számú válto- 
zatban telepítette. (7. ábra) 

A Fedora Core 2 ugyancsak RPM alapú, vagyis terminál alól 
használhatjuk az rpm parancsot is. 

Egy további ismert csomagkezelő felület a Yellow dog Updater 
Modíified, röviden Yum. A Yum sokban hasonlít az APT-hez, 
ám sokban el is tér tőle, a különbségeket a szerző részletesen 
ismerteti a Yum weboldalon. A Yum az urpmi és az APT eseté- 
ben látottakhoz hasonló csomagforrásokkal dolgozik, és 

a csomagok telepítését az RPM-re bízza. Az anaconda telepítő 
Python kötéseket használ az RPM elérésére, így a Python tá- 
mogatásának fennmaradására bátran számíthatunk. 


Osszefoglalás 

Van egy mondás a baseballban: , Annyira vagy jó, amennyire 
az utolsó ütésed." A számítógépek világában ezt úgy fogal- 
mazhatnánk meg, hogy egy gép annyira biztonságos, 
amennyire az utolsó frissítés révén azzá vált. Egy jó tűzfal 
vagy egy mágneskártyás beléptetős bejárat kiváló kezdő lépés 
a biztonság megteremtése felé, ám ne feledjük, ha elmulaszt- 
juk a frissítések telepítését, és elavult Apache- vagy OpenSSH- 
változatot futtatunk, teljes rendszerünk veszélybe kerülhet. 


Linux Journal 2005. január, 129. szám 


Jeremy Turner több mint öt éve használja 

a Linuxot. Szenvedélye, hogy segítsen másokat 
a nyílt alkalmazások megismerésében. PHP-ben 
programoz, egy kórusban első tenor, rengeteg 
baseballt néz, elektronikus leveleit pedig rend- 
szeresen olvassa (Jeremyeolinuxwebguy.com). 





Levéltitkosítás egyetlen kattintással 


A titkosított levelek küldését, fogadását és ellenőrzését grafikus eszközökkel 
végezve a biztonságos levelezés mindennapjaink természetes részévé válhat. 


szal, és nem szeretném, hogy mások is el tudják ol- 

vasni a leveleimet, ha netán rossz kezekbe kerülne. 
Leveleimet figyelik is, és az se tetszene, ha a rendszergazda 
belelátna a személyes dolgaimba. A GnurG kiváló titkosítási 
lehetőséget kínál, és bárki számára elérhető. A KDE KGPG 
és KMail alkalmazásával a dolgok még egyszerűbbekké vál- 
nak. Írásomban a KGPG elektronikus levelek és fájlok titko- 
sítására való használatát tárgyalom. Lehet, hogy a téma ki- 
csit összetettnek fog tűnni, ám mire a végére érünk, bárki 
üzemképes rendszerrel rendelkezhet — ráadásul mindehhez 
elég lesz egy óra. Ha valakinek kérdése maradna, nyugod- 
tan írjon a cikkben szereplő címemre, legalább ki tudja pró- 
bálni új, biztonságos levelezőrendszerét. 


Mi az a GnuPG? 
A Gnu Privacy Guard (GnuPG) az OpenPGP szabvány egy 


megvalósítása. A szabvány Philip Zimmerman munkája 
nyomán és PGP (Pretty Good Privacy) programjából fejlő- 
dött ki. A PGP 1991 tájékán jelent meg, jelenleg zárt alkal- 
mazás. Az OpenPGP szabványok 1997-ben készültek el, 

a GnuPG 1.0-s változata pedig 1999-ben látott napvilágot. 

A GnuPG teljes egészében parancssori program, és megle- 
hetősen bonyolult a kezelése. Szerencsére léteznek a hasz- 
nálatát megkönnyítő eszközök, ezek közül a KDE, a KGPG 
és a KMail szerepéről lesz szó. 

A GnurG és a PGP egymással kompatibilisek. Aki már hasz- 
nálja a PGP-t, azon belül is az IDEA algoritmust, annak némi 
munkával jár az áttérés, a többiek számára viszont semmi- 
lyen nehézséget nem okoz. Ha valakinek PGP 2.x változattal 
kell adatcserét folytatnia, esetleg ezt a programot szeretné 
lecserélni, akkor tanulmányozza át a cikkhez tartozó forráso- 
kat, a $ www.linuxjournal.com/article/7863 címen. 

Az adatvédelmi és adatbiztonsági házirendek összeállításá- 
hoz és betartatásához minden szervezetben vasfegyelemre 
van szükség. Amikor katonai hírszerzőként dolgoztam, 

a biztonságot nagyon komolyan vették. Ha valaki nem kö- 
vette a házirendeket, annak súlyos következményei voltak. 
Minden szervezetben ki kell jelölni egy biztonsági igazga- 
tót, akinek megfelelő hatalmat kell biztosítani az irányelvek 
követésének ellenőrzésére. Mint minden jól kidolgozott 
gyakorlati megoldásnál — mint például a CVS használata 

a kódok tárolására -, ha az embereket megtanítjuk, rászok- 


b ómagam egy hordozható gépet használok Linux- 
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File Edit View Keys Groups Settings Help 

13 419 8 év 

Name e i . Email Trust 
t-eZRoy Hocbler royhooblera... [DE] Untimited 1024 06/10/04 
1-€aRoy Hoobler royaconnect... [/DETE]. Untimited 1024 05/20/04 
t-eZRoy Hoobler rhooblerfjco... [EI Unlimited 1024 05/20/04 








. Expiration Size Creation "d 

(DXEEFOB87C 
0x904B4258 
0x5E486A92 


My Keys 


1. ábra A kulcskezelő eszköz segítségével a GnuPG kulcsok között 
név és levélcím alapján Is kereshetünk 


tatjuk az érzékeny adatok titkosítására, akkor az eljárás hét- 
köznapivá válik. A szervezet méretétől függően a házirend 
hatályba léptetése egy-négy hét alatt végbe vihető. 


Saját kulcsunk előállítása 

Példaként egy üzenetet fogok titkosítani, majd elküldöm 
azt munkahelyi címemről az rhoobler(vcomcast.net címem- 
re. Mindkét fiókot KMail segítségével érem el. Ezután kül- 
deni fogok egy titkosított választ a munkahelyi címemre. 
lermészetesen előbb beállítom és elérhetővé teszem 

a comcast.net fiók kulcsait. 

Miután telepítettük a KGPG-t, a rendszertálcán kell hozzá 
tartoznia egy ikonnak. Ha nem lenne ilyen, akkor terminál 
alól, a KGPG -k paranccsal tudjuk elindítani. A -k kapcsolót 
ne hagyjuk el, ugyanis ez hozza elő a kulcskezelő felhasz- 
nálói felületet. (1. ábra) A -k kapcsoló nélkül indítva a KGPG 
a háttérben, szolgáltatásként fut — ilyenkor jelenik meg 

a tálcán az ikonja. A felhasználói felület a tálcán található 
ikonra kattintva is megjeleníthető. 

Első lépésként előállítom comcast.netes fiókom nyilvános 
és magánkulcsát. A kulcskezelőn belül válasszuk a Keys: 
Generate Key Pair (Kulcsok: Kulcspár előállítása) parancsot, 
amely egy meglehetősen egyszerű párbeszédpanelt jelenít 
meg. Ha az Expert Mode-ot (Szakértői mód) választjuk, 

a GnuPG terminálban indul. Most írjuk be nevünket, elekt- 
ronikus levélcímünket, illetve a kívánt megjegyzést. A biz- 
tonsági házirendtől függően szükség lehet arra is, hogy 

a kulcsok lejáratát is beállítsuk. 

A következő - rendkívül fontos - lépés a GnuPG jelszó 
megadása. Ha elhagyjuk, akkor egyetlen üzenetet sem 
tudunk majd megnyitni, a KGPG mindig jelszót fog kérni 
tőlünk, amikor bármit is megpróbálunk elolvasni. Várjunk 
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néhány másodpercet, amíg a GnuPG elkészíti kulcsainkat. 
A biztonság növelése érdekében javaslom egy visszavonási 
tanúsítvány (revocation certificate) elkészítését is (a fájl ne- 
ve olyasféle legyen, mint az rhooblerrev.asc). Ha ellopják 
vagy megtörik a gépünket, akkor ezt a tanúsítványt szét- 
küldve értesíthetjük ismerőseinket nyilvános kulcsunk 
érvénytelenné válásáról. 

Ennyi. Van nyilvános és titkos kulcsunk az 
rhoobler(wvcomcast.net címhez. Két dolog van még hátra: 

a nyilvános kulcs és a titkos kulcs kimentése, utóbbi művelet 
elhagyható. A kulcsok kimentése külön-külön történik. 

A nyilvános kulcsnál az rhoobler.asc fájlnevet választottam, 

a titkos kulcs esetében pedig az rhooblerprivate.asc-t. Vigyáz- 
zunk! Ha valaki megszerzi titkos kulcsunkat, és kitalálja jel- 
szavunkat, akkor el tudja olvasni titkosított leveleinket, vala- 
mint a nevünkben tud titkosított, aláírt leveleket küldeni! 

A titkos kulcsot és a visszavonási kulcsokat kimentésük 
után írjuk CD-lemezre, helyezzük őket biztonságos helyre, 
majd töröljük a visszavonási (rhooblerrev.asc) és a titkos kul- 
csot (rhooblerprivate.asc) a merevlemezről. 

A GnuPG a következő fájlokat helyezi el az egyes felhasz- 
nálók .gnupg könyvtárába. A fájlokat csak az egyes felhasz- 
nálók tudják írni és olvasni: 


e  gpg.conf: a GPG általános beállításai 

e . pubring.gpg: a nyilvános kulcsok listája 

e  secring.gpg: a biztonságos (magán) kulcsok listája 

e  trustdb.gpg: adatbázisfájl, az egyes személyek közötti 
megbízási viszonyokat adja meg 


A kényelem kedvéért most az rhoobler(acomcast.net nyilvá- 
nos kulcsát egy alapértelmezett kulcskiszolgálóra mentem 
ki. A kulcskezelő eszköz segítségével válasszuk ki a kulcsot, 
kattintsunk rá az egér jobb gombjával, majd válasszuk az 
Export Public Key(s) (Nyilvános kulcs(ok) kimentése) paran- 
csot. Újabb egyszerű párbeszédpanel jelenik meg, három 
lehetőséggel. Én az alapértelmezett kulcskiszolgálót válasz- 
tottam, majd az OK gombra kattintottam. A kulcskiszolgálót 
a Settings (Beállítások) menüben adhatjuk meg, alapeset- 
ben ez a subkeys.pgp.net, ami — legalábbis nálam — mindig 
működött. Megtehetjük azt is, hogy fájlba mentjük ki 

a kulcsot, majd elektronikus levélben továbbítjuk, esetleg 

a weboldalunkon tesszük közzé. Abból, hogy bárki megis- 
merheti a nyilvános kulcsunkat, semmi gondunk nem 
származhat, ám módot kell adnunk a kulcs eredetiségének 
ellenőrzésére — erről később lesz szó. Aki rendelkezik a nyil- 
vános kulcsunkkal, az képes lesz fájlokat úgy titkosítani, 
hogy azokat csak mi tudjuk majd megnyitni. 

Eljutottunk tehát odáig, hogy tudunk fájlokat titkosítani és 
titkosított leveleket küldeni. Mindennek azonban csak ak- 
kor van értelme, ha van kivel megosztanunk adatainkat. 

A próba kedvéért én átsétáltam a másik gépemhez, majd 
ugyanezeket a lépéseket végrehajtva létrehoztam a kulcso- 
kat a munkahelyi levélfiókomhoz. 

A következő művelet az rhoobler(ocomcast.net nyilvános 
kulcsának beemelése a kulcskiszolgálóról a kulcskezelő 
segítségével, majd a földgömb ikon vagy a menü File:Key 
Server Dialog (Fájb. Kulcskiszolgáló párbeszéd) parancsának 
kiválasztása. Adjuk meg az elektronikus levélcímet, majd 
emeljük be a kulcsot. Mielőtt használni kezdenénk a kul- 
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2. ábra Ha ellenőrizni akarjuk egy levél hitelességét, akkor hívjuk fel 
a küldőt, és egyeztessük vele a kulcs ujjlenyomatát 
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signerify , Enerypt Decrypt 


3. ábra A vágólap visszafejtése 


csot, válasszuk ki a főablakban, majd válasszuk a menü 
KeysSign Keys (Kulcsok: Kulcsok aláírása) parancsát. 

Ha nagyobb csoportot akartam volna összeállítani, akkor 
létrehozhattam volna egy saját kulcskiszolgálót, aláírhattam 
volna a kulcsokat és továbbadhattam volna őket. Egy másik 
megoldás, hogy mindenki elküldi levélben másoknak saját 
kulcsát, majd a való életben is találkoznak, amikor ellenőr- 
zik és aláírják egymás kulcsát. Így jön létre a bizalmi háló- 
zat. Én például aláírom Berci kulcsát, ő pedig Katiét. Ha le- 
velet kapok Katitól, akkor kulcsát nyugodtan hozzáadha- 
tom megbízási viszonyokat tároló adatbázisomhoz. 

A kulcsoknak van egy ujjlenyomatuk, és ha nem vagyok 
biztos abban, hogy egy kulcs hiteles-e, akkor megnézhetem 
az ujjlenyomatát, majd felhívhatom a tulajdonosát, és segít- 
ségével ellenőrizni tudom a kulcsot. Az ujjlenyomat a kulcs- 
kezelő segítségével tekinthető meg, ehhez válasszuk ki 

a kulcsot, majd válasszuk a menü Edit Key (Kulcs szerkesz- 
tése) parancsát. (2. ábra) 


Fájlok titkosítása 

A KGPG-t szinte észrevétlenül beépítették a KDE-be 

és a KDE-s alkalmazásokba. Ennek előnyeit leginkább 

a Kongueror böngésző használatakor élvezhetjük. A KGPG 
telepítése után kattintsunk az egér jobb gombjával a kívánt 
dokumentumra, majd az Actions (Műveletek) menüben lét- 
rehozhatjuk a dokumentum titkosított változatát. Lehető- 
ség nyílik az eredeti példány megsemmisítésére is, aminek 
főleg akkor van értelme, ha a titkosítatlan változat megtar- 
tása valamiért nemkívánatos. A fájlok titkosításakor több 
kulcsot is kiválaszthatunk, így több különböző személy is 
el tudja olvasni a dokumentumot. Ha az eredeti fájlt meg- 
semmisítjük, akkor ügyeljünk arra, hogy a titkosítás során 
saját kulcsunkat is kiválasszuk. Nálam, ha például csak az 
rhoobler(ocomcast.net kulcsot választom ki, akkor én leszek 
az egyetlen, aki vissza tudja fejteni a fájlt. 


Elektronikus levél küldése 

Végre készen állunk arra, hogy titkosított leveleket küld- 
jünk. A KMail (vagy a Kontact) segítségével írjuk meg üze- 
netünket. Nálam a címzett az rhoobler(ocomcast.net. Kattint- 
sunk a Lock ikonra, vagy válasszuk az Options: Encrypt 
(Beállítások: Titkosítás) parancsot a menüből. Amikor a Send 
(Küldés) gombra kattintunk, egy párbeszédpanel jelenik meg. 
Ha nem látjuk a címzett kulcsát, kattintsunk a Refresh (Frissí- 
tés) gombra. Ha nem írtuk alá a kulcsot, nem fog megjelenni, 
ekkor vissza kell lépnünk, a kulcskezelő segítségével alá kell 
írnunk a kulcsot, majd rá kell kattintanunk a Refresh gombra. 
Fejezzük be az üzenetet, majd kattintsunk a Send gombra. 

A KMail esetében az üzenetek visszafejtése beépített szol- 
gáltatás. Ha titkosított üzenetet kapunk, csak be kell írnunk 
a jelszót, és máris megnyílik az üzenet. Ha titkosított üzene- 
tet küldünk, és a címzett címe szerepel a kulcsgyűrűnkben, 
akkor a levél titkosítása és elküldése önműködően történik. 
Az üzenetet egyszerre több embernek is elküldhetjük titko- 
sítva, feltéve, hogy mindannyiuk nyilvános kulcsával ren- 
delkezünk. lovábbi lehetőség a fájl KGPG segítségével 
végzett titkosítása, majd mellékletként való továbbítása. 

A KMail önműködően visszafejti a mellékleteket; ehhez 
egyébként a megtekintés, és nem a megnyitás parancsot 
kell választanunk. Ha webes levelező ügyfelet használunk, 
akkor töltsük le a fájlt, majd a Konguerorral tudjuk vissza- 
fejteni vagy megnézni a tartalmát. Ha olyan webes levele- 
zőt használunk, mint például a Yahoo mail, akkor másoljuk 
ki a vágólapra a titkosított üzenetet, az egér jobb gombjával 
a tálca ikonjára kattintva válasszuk a Decrypt clipboard 
(Vágólap visszafejtése) parancsot, majd illesszük be a vágó- 
lap tartalmát a KGPG szerkesztőjébe. Hasonló módon lehet 
elvégezni az üzenetek titkosítását is. 


Elektronikus levél aláírása 
A titkosításnál népszerűbb alkalmazás a levelek aláírása. 
Ilyenkor maga a szöveg nem kerül titkosításra, ám az alá- 
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írás igazolja az üzenet hitelességét. Ha minden levele- 
met aláírom, mert ez a házirend, és valaki kap tőlem egy 
aláíratlan vagy hibás aláírású levelet, akkor nyugodtan 
feltételezheti, hogy hamis, és értesítheti a megfelelő sze- 
mélyt. A KMail a leveleket különféle színekkel jelöli meg, 
a színekből tudhatjuk, hogy az egyes üzenetek megbízha- 
tó féltől érkeztek-e. Sárgák az aláírt, zöldek az aláírt és 
megbízható levelek. 


Csoportok létrehozása és egyéb lehetőségek 

A KGFEG további érdekes szolgáltatása a kulcscsoportok lét- 
rehozásának lehetősége. Lehet például egy Felügyelet cso- 
portom, amelybe három-négy kulcsot helyezek el. Uzenet 
küldésekor ki tudom választani a csoportot. Később, ha az 
egyik címzett továbbítja a levelet a csoport egy másik tagjá- 
nak, akkor az már készen fog állni az elolvasásra. 

A Configure KGPG (KGPG beállítások) alatt az ASCII 
Armor (ASCII védelem) beállítást is érdemes engedélyezni, 
ahogy valószínűleg ez is az alapbeállítás. Ilyenkor az alá- 
írások és a titkosítás tisztán szövegesen tárolódnak, így 
könnyebben lehet továbbítani, nyomtatni, másolni és beil- 
leszteni az anyagot. Az ASCII védelem kikapcsolásakor 
bizonyos fájlok bináris formátumot kapnak, ami esetleg 
gondokat okozhat. 


Összegzés 

Amint lesz időm, ígérem, minden titkosított bejövő leve- 
lemet vissza fogom fejteni, és válaszolni is fogok. Mivel 

a KGEG a KDE tésze, a legtöbb Linux terjesztésben eleve 
megtalálható. Néhány kulcsot létrehozni és kipróbálni 

a lehetőségeket mindössze egy-két órát igényel. 

A GnuPG és a KGLCG telepítése után a kulcsok és a titkosítás 
használata a mindennapok gyakorlatában sem okozhat 
gondot, ha ügyelni akarunk a biztonságra. Eddigi munkáim 
során mindig nagy figyelmet fordítottak az összeköttetések 
és például az SSL feletti tranzakciók biztonságára, ám a fáj- 
lok és az elektronikus levelek valahogy kiestek ebből a kör- 
ből. KDE használatakor a biztonságos levelezőrendszer 
megteremtése nem okozhat különösebb nehézséget. Érde- 
mes úgy kezdeni, hogy először csak a felettünk álló veze- 
tőknek szánt leveleket titkosítjuk; vagy jó ötlet lehet olyan 
magánmappát nyitni a hálózaton, amely kizárólag titkosí- 
tott dokumentumokat tárol. Ha ezeket a biztonsági háziren- 
deket már elfogadtattuk, a szélesebb körű titkosítást is 
könnyebb lesz megvalósítani. 
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A gyökér fájlrendszer titkosítása 


Ha adataink fizikai biztonságát nem tudjuk garantálni, akkor nincs más lehetősé- 
günk, mint a fájlrendszer titkosítása. Bár írásomban egy PowerPC alapú rendszer 
átalakítását fogom taglalni, az alapelvek más géptípusokon is változatlanok. 


Linuxvilág , Titkosított saját könyvtárak megvaló- 
A sítása" (2003 október) című cikkében már ismertet- 

tem, hogyan lehet átlátszó módon titkosítani 
a kezdőkönyvtárakat. Ez alkalommal egy másik megoldást 
szeretnék ismertetni, a gyökér fájlrendszer titkosítását. Szó 
lesz a GNU/Linux rendszertöltési folyamatáról és a szüksé- 
ges programokról, adok némi további útbaigazítást, megis- 
merkedünk az Open Firmware-rel és néhány további figye- 
lembe veendő tényezővel. A fogalmakat egy a Fedora Core 3 
előzetes kiadását futtató, New World PowerPC alapú Apple 
iBook alapján ismertetem. lermészetesen az itt szereplő fo- 
galmak és eljárások bármely készüléken, géptípuson és 
operációs rendszeren érvényesek, alkalmazhatók. Feltétele- 
zem, hogy rendelkezünk egy különálló USB-s flash memó- 
ria egységgel, továbbá a gép belső programja képes a róla 
végzett rendszerindításra. 
Feltételezem továbbá, hogy az olvasó már jártasságot szer- 
zett a forrásfoltok telepítésében és a programok fordításá- 
ban. A Fedora Core 3 Test 3 terjesztés esetében az mkinitrd 
és az initscripts csomagokat kell megfoltozni a titkosított 
gyökér fájlrendszer támogatásával. Nem árt, ha a lemezkö- 
tetek kezelésével és a fájlrendszerek létrehozásával is tisztá- 
ban vagyunk. A Linux terjesztések alapszintű telepítésével 
itt nem áll módomban foglalkozni. 
Mielőtt rátérnénk a műszaki jellegű kérdésekre, meg kell 
ismernünk egy magasabb szintű fogalmat, a megbízás fo- 
galmát. A megbízás kifejezést leginkább titkosítási és hitele- 
sítési témák kapcsán hallhatjuk. Az elektronikus kulccsal 
rendelkező készülékeket alapesetben megbízhatókként ke- 
zeljük. Például, ha beírom a PIN-kódomat egy pénzkiadó 
automatába, akkor feltételezem, hogy nem fogja harmadik 
félnek kiadni azt. Hasonlóan, amikor beírok egy titkosítási 
kulcsot a számítógépembe, feltételezem, hogy nem fogja 
másnak átadni. Megbízom a számítógépemben, titkunk 
a kettőnké marad. 
No de valóban megbízhatunk a számítógépünkben? 
Hacsak nem visszük mindenhova magunkkal, nyilván 
nem! Akkor is igaz ez, ha a lemezek titkosítva vannak. 
Vegyük a következő forgatókönyvet: míg alszunk, valaki el- 
lopja a gépünket. A tolvaj — noha a visszafejtő kulcs hiányá- 
ban egyelőre nem tud mi kezdeni vele — másolatot készít 
gépünk tartalmáról. Ezután a gép titkosított tartalmát lecse- 
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réli, majd visszateszi a gépet a helyére. Amikor másnap 
reggel felébredünk, a gép, ahogy minden nap, kéri tőlünk 

a kulcsot. Ez alkalommal azonban, amint megadjuk a kul- 
csot, elküldi azt a tolvajnak. Mivel most már adatainkkal és 
a kulcsunkkal egyaránt rendelkezik, el tudja olvasni doku- 
mentumainkat. 

lermészetesen a példa kicsit erőltetett, de rendkívül szem- 
léletes. A lényege az, hogy nem bízhatunk meg a számító- 
gépünkben, hiszen nem tarthatjuk minden pillanatban 
szem előtt. Bármilyen jó is tehát a titkosítási rendszerünk, 
bizalmi alap nélkül épül fel. 

Ha biztosítani akarjuk a számítógép rendszertöltési folya- 
matának megbízhatóságát, akkor el kell különítenünk tőle. 
A gondolat nem új, hiszen az autónknak is csak a kulcsát 
hordjuk magunkkal, magát az autót a parkolóban hagyjuk. 
A titkosítási kulcs természetes analógiája az autókulcsnak. 
A titkosítási kulcs könnyebben védhető, így a számítógépet 
nem kell mindenhová magunkkal vinnünk. Ennél egy kicsit 
tovább is lépünk, és a probléma megoldása céljából a számí- 
tógép indításához szükséges programot is a kulcson helyez- 
zük el. A kulcs szerepét a flash meghajtó játssza. A rend- 
szerindításért felelős program és a titkosítási kulcs együttes 
védelmével komolyan csökkenthetjük a rendszertöltő folya- 
mat meghamisításának kockázatát. 

Ehhez érteni kell a számítógép indításának folyamatát, 
ugyanis a titkosított gyökér fájlrendszer feloldása a rend- 
szertöltő folyamat nélkülözhetetlen része. A jelenlegi üzem- 
biztos, vagyis 2.6-os rendszermagok képesek az initramfs 
segítségével végzett rendszerindításra. (Lásd: LWN.net, 
,Initramfs Arrives") Az initramfs egy cpio archív, a rend- 
szermag most már tudja, hogyan bonthatja ki ezt egy RAM- 
lemezre. A kibontott fájlrendszer egy parancsfájlt tartalmaz, 
mely hagyományosan egy a gyökér fájlrendszer befűzésé- 
hez szükséges rendszermagmodulokat betöltő parancsfájlt 
tartalmaz. Esetünkben ez a parancsfájl végzi majd a titkosí- 
tott gyökér fájlrendszer visszafejtését is. A témáról bővebb 
tájékoztatást a Linux rendszermagforrások részeként elérhe- 
tő buffer-format.txt és initrd.txt fájlokban lehet találni. 
Linux alá számos fájlrendszer-titkosító felület létezik. 

Jari Ruusu Loop-AES megoldása is egy ezek közül. Számos 
cryptoloop változat is készült, ezek titkosított hurokeszközt 
biztosítanak. Írásomban a jelenlegi, 2.6-os rendszermagok 
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által nyújtott dm-crypt felülettel foglalkozok. A Fedora Pro- 
ject jelenleg ezt a felületet helyezi előtérbe, és a dm-crypt 
modulok is szerepelnek a Fedora rendszermagcsomagjai 
között. Szükséges továbbá egy állandó jelleggel csatolt 
cryptsetup. Segítségével leegyszerűsödik a dm-crypt eszkö- 
zök kezelése. Végül, a rendszerindító fájlrendszer kezelésé- 
re a parted és a hfsutils szolgál. 

Sajnos a Fedora Core anaconda telepítője alapesetben jelen- 
leg nem támogatja a titkosított fájlrendszerre telepítést. 
Korlátain úgy léphetünk túl, hogy egy lemezrészt szabadon 
hagyunk, telepítjük a Fedorát, megformázzuk titkosítottra 

a szabad lemezrészt, majd a telepítő által felmásolt fájlokat 
átmozgatjuk a titkosított részre. Az egyszerűség kedvéért 
feltesszük, hogy a Fedora telepítését két lemezrész használa- 
tával végezzük: a /dev/hda4 a /home, a /dev/hda5 pedig a / 
elérési úttal van befűzve. Mivel a /home csak a Fedora telepí- 
tése után kerül feltöltésre, a /dev/hda4 lesz a tartalék lemez- 
rész, a /dev/hda3 pedig a cseretár. 

Fűzzük be a /dev/hda4 meghajtót a /home, a /dev/hda5 meg- 
hajtót pedig a / elérési út alá, és telepítsük a Fedora Core 3 
terjesztést. A root-on kívül ne adjunk hozzá felhasználókat, 
mert a /home tartalma a későbbiek során törlésre kerül. 
Ezen a ponton kapunk egy teljes értékű Linux rendszert. 
Mielőtt létrehoznánk a titkosított fájlrendszert, véletlen- 
szerűsítenünk kell az általa elfoglalandó lemezrészt. Ezzel 
megelőzhetjük a lemez tartalmával kapcsolatos adatok ki- 
szivárgását. Az 1. ábrán egy elvonatkoztatott lemez látható, 
mely félig van tele, és véletlenszerűsítése nem volt megfe- 
lelő. A 2. ábrán egy olyan lemez látható, melynek véletlen- 
szerűsítését helyesen elvégezték, mielőtt megformázták 
volna a titkosított fájlrendszerrel. Vegyük észre, hogy az 1. 
ábra lemezéről lehet némi információt szerezni, például 
meg lehet állapítani, hogy az adatok csak félig töltik ki. 

A 2. ábrán látható lemeznél ilyesmitől nem kell tartani, 

a lemez akár teli, akár üres is lehet. Egy lemezrész vélet- 
lenszerűsítése tartalmának véletlenszerű adatokkal való 
felülírásával történik: 


dd 1f-/dev/urandom of-/dev/hda4 


A művelet végrehajtása eltarthat egy ideig, ugyanis a vélet- 
lenszerű adatok előállítása nem egyszerű feladat. 


www.linuxvilag.hu 


irt CT BEKE Terez] TFAzet SETA : 
Ü MT 1 Kek yi TOGiH EL ren fr ahi 
he ; ha era I ; I Í j 1 Hg vi e 


A /dev/hda4 meghajtón az alábbi lépéseket követve hozha- 

tunk létre titkosított ext3 fájlrendszert: 

1) Ellenőrizzük, hogy az aes, a dm-mod és a dm-crypt 
modul be van-e töltve a rendszermagba. 

2) Válasszuk le a /home elérési út alól a titkosított gyökér 
fájlrendszer tárolására kiszemelt meghajtót vagyis 
a /dev/hda4-et: 


$ umount /dev/hda4 


3) Hozzunk létre egy véletlenszerű, 256 bites titkosító 
kulcsot, és mentsük el /etc/root-key néven: 


ft dd 1f-/dev/urandom of-/etc/root-key bs-1c 
count-32 


A kulcsot később át fogjuk másolni a flash meghajtóra. 


4) Hozzunk létre egy dm-crypt eszközt, mely az imént lét- 
rehozott kulccsal kerül titkosításra: 


ft cryptsetup -d /etc/root-key create root /dev/hda4 


A /dev/mapper/root most egy titkosított réteget szolgáltat 

a /dev/hda4 felett. Alapesetben a cryptsetup egy AES algo- 
ritmussal titkosított dnm-crypt eszközt hoz létre, és 256 bites 
kulcstér használatát feltételezi. 


5) A/dev/mapper/root alatt hozzunk létre egy ext3 fájlrend- 
szert: 


ft mkfs.ext3 /dev/mapper/root 
6) Fűzzük be az új fájlrendszert: 


ft mkdir /mnt/encroot 
ff mount /dev/mapper/root /mnt/encroot 


7) Kész a titkosított fájlrendszer, fel kell töltenünk a /dev/ 
hda5, azaz az eredeti gyökér fájlrendszer tartalmával: 


f cp -ax / /mnt/encroot 


8) Végül létrehozunk egy bejegyzést a /mnt/encroot/etc/ 
crypttab fájlban, a különféle segédprogramok innen 
tudhatják meg, hogy melyek a fájlrendszer beállításai: 

root  — /dev/hda4 /etc/root-key 6 cipher-aes 

A titkosított fájlrendszer is készen áll, a továbblépéshez azon- 

ban ismernünk kell gépünk rendszertöltési folyamatát. 

A számítógépek általában rendelkeznek valamilyen belső 

programmal, ez adja át a vezérlést a rendszertöltést végigvi- 

vő programnak. A belső program védelmének tárgyalása túl- 
mutatna a cikk témáján, ezért feltételezzük, hogy a rendszer 
belső programja megbízható. A legtöbb olvasó számára való- 
színűleg ismerős a BIOS, a PC alapú gépek által használt 
rendszertöltő belső program. Itt az Open Firmware rendszer- 
töltővel foglalkozok, ezt több gyártó is alkalmazza, például 
az Apple, a Sun és az IBM. 
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Szaktekintély 


A NetBSD/macppc telepítési útmuta- 
tója kiváló ismertetőt tartalmaz az 


Open Firmware-hez. Célunk az, hogy 


az Open Firmware parancssoros felü- 
letének segítségével eltávolítható 
flash meghajtóról végzett rendszer- 
indításra állítsuk be a számítógépet. 
Az Open Firmware lehetővé teszi 

a számítógéphez csatlakoztatott ké- 
szülékek megtekintését, továbbá 

a belső program változóinak megte- 


kintését és módosítását. 


Nyílt firmware 


Nyílt firmware 


ofboot.b környezet 





Szereztünk némi betekintést a belső 
programnak a számítógépről alko- 
tott képébe, ezért térjünk át a belső 
program által kezdésként futtatott 
program, vagyis a rendszertöltő vizs- 
gálatára. Az Apple PowerPC gépein 
futó Linux rendszerek általában 

a yaboot nevű program közreműkö- 
désével indítják a gépet. A vaboot 
hasonló a LILO-hoz vagy a GRLIB- 
hoz, és két kulcsprogramot tartal- 
maz, az ofboot.b-t és a vabootot. Az 


ofboot.b a rendszertöltés első fázisá- 
ról gondoskodik. Lényegében az 
ofboot.b feladata az indítandó operá- 
ciós rendszer kiválasztása. Ha példá- 
ul a rendszerre a Mac OS X és 

a Linux is telepítve van, akkor az 
ofboot.b indítja el a Mac OS X vagy 
a Linux rendszertöltőjét. Ha a fel- 
használó a Linux betöltése mellett 
dönt, az ofboot.b a yabootot indítja 
el, mely a rendszertöltési folyamat 
második fázisát képviseli. A vaboot 
ezután betölti a Linux rendszerma- 
got, és jelen esetben az initrd-t. 

A 3. ábra a Linux titkosított gyökér 
fájlrendszerről való elindítását szem- 
lélteti (PowerPC géptípuson). 
Eltávolítható rendszerindító eszkö- 
zünkre az ofboot.b és a yvaboot prog- 
ramot, egy Linux rendszermagot, 
valamint a titkosítási kulcsot tartal- 
mazó initrd-t kell rámásolnunk. Az 
Apple jelenlegi PowerPC alapú gé- 
pei a rendszerindításra használt 
adathordozón HES fájlrendszert 
várnak. 


Az Open Firmware parancssorát a New 
World (G3 vagy újabb) Apple gépeken 
az OPTION-COMMAND-O-HF billentyű- 
kombináció rendszertöltés közben va- 
ló lenyomásával lehet elérni. 

Azt, hogy a rendszer melyik eszközt 
használja a rendszertöltésre, a boot- 
device változó határozza meg. 

A változó értékét a printenv 
paranccsal vizsgálhatjuk meg: 


Más operációs 
rendszer 
betöltőmodulja 
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yaboot.conf 
Rendszermag 


1. Kibontja az initrd 
állományt és elhelyezi 
egy memórialemezen 


Í init szkript 
s printenv 
[...7 2. Végrehajtja az init 


; folyamatot 1. Betölti 
haz Atxbi MENSEESKÉS 88 


boot-device a magmodulokat 


s hd: W:txbi 


2. Visszafejti a gyökér 


A fenti sor értelmezése a következő: fájlrendszert 


A rendszerindítást az első IDE leme- 
zen található, HES típusú txbi fájl 
futtatásával kell elvégezni". A máso- 
dik kettőspont, mely a txbi előtt ta- 
lálható, a zseton HES fájltípusként 
való értelmezését váltja ki. Egyéb- 
ként a program a txbi-t egy fájl 


SA A ET akó 


3. Becsatolja a gyökér 
fájlrendszert 


4. Átvált az új gyökér 
fájlrendszerre 


3. Végrehajtja az 
/Ssbin/init folyamatot 
az igazi gyökér 
fájlrendszeren 


temben a hd zseton valójában 

egy álnév a jóval bonyolultabb 
/pci14f4000000/ata-6€4d/di1 sk(0 
eszközhöz. A karakterlánc az első 
IDE merevlemez különféle alrend- 


1) A parted programmal hozzuk 
létre a megfelelő, indításra is 
használható lemezrészt a flash 
meghajtón. (Saját meghajtóm 64 
MB-os, és a /dev/sda eszközcso- 
móponton keresztül érhető el.): 





3. ábra Open Firmware-rel ellátott, PowerPC alapú 
szereken keresztül vezető elérési út- rendszer indításának folyamata 
ját adja meg. Azt, hogy egy álnév 

melyik eszközhöz tartozik, az Open 

Firmware devalias parancsával tekinthetjük meg. 

A boot-devi ce, a rendszerindító eszköz beállításához meg 
kell tudnunk, hogy az Open Firmware milyen névvel azo- 
nosítja flash meghajtónkat. Az Is paranccsal kapott eszköz- 
fát megvizsgálva azonnal fény derül a flash meghajtó eléré- 


f parted /dev/sda 

(parted) mklabel mac 

(parted) print 

Disk geometry for /dev/sda: 0.000-62.500 megabytes 


si útvonalára: Disk label type: mac 


Minor — Start End Filesystem Name Flags 
s5 dev / Is 1 0.000 0.031 Apple 
[...] (parted) mkpart primary hfs 0.031 62.500 
/pc14f2000000 (parted) print 
hsz Disk geometry for /dev/sda: 0.000-62.500 megabytes 
/usbalb,1 Disk label type: mac 
(sze Minor Start End Filesystem Name Flags 
/disk(a1 1 0.000 0.03 Apple 
Ess 2 0.031 62.500 untitled 
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Titkosított fájlok 
olvasása 


Az adatok 
és a kulcs 
megszerzése 


Adatok olvasása 
a visszafejtés 
során 


A számítógép és 
a kulcsot tartalmazó 
USB flash memória 

ellopása 


Támadás a gép 
ellen, miközben 
a hálózatra 
csatlakozik 


A gép ellopása, a lemez 

lemásolása, a firmwire 

módosítása, majd a gép 
visszacsempészése 


A kódolatlan 
adatvesztés 
eltulajdonítása 


A tulajdonos 


2. ábra Hogyan tudja egy támadó olvasni a titkosított fájlrendszert? 


(parted) set 2 boot on 
(parted) name 2 Apple Boot 
(parted) guit 


2) Hozzuk létre a HFS-t a rendszertöltő lemezrészen: 
ft hformat /dev/sda2 


3) A /mnt/encroot/etc/yaboot.conf módosításával állítsuk 
be a yabootot a megfelelő eszközről végzett rendszerin- 
dításra. Az alábbiakban egy minimális beállításkészlet 
szerepel: 


boot-/dev/sda2 
ofboot-/pci14f2000000/usbatflb, 1/diskal1: 2 
partit1on-2 
instal 1-/usr/11b/yaboot/yaboot 
magi cboot-/usr/1ib/yaboot/ofboot 
default-]linux 
1mage-/vmlinux 
label-linux 
root-/dev/hda4 
1nitrd-/initrd.gz 
read-only 


A /pcidf2000000/usbálb, 1/diska1:2 érték az Open 
Firmware eszközfájának korábbi vizsgálatából származik, 
a /pcidf2000000/usbálb, 1/disk€1 pedig a f2000000 cí- 
men elérhető PCI busz első USB buszának első lemeze. 

A bennünket érdeklő eszköz egy lemez (disk), a : 2 jelölés 
pedig a második lemezrészre utal. 


4) lIelepítsük a rendszertöltő programokat és a rendszer- 
magot a /dev/sda2-re: 


f ybin -config /mnt/encroot/etc/yaboot. conf -v 
f mount /dev/sda2 /media/usbstick 
ft cp /boot/vmlinux /media/usbstick 


A következő lépés a titkosításra képes initrd telepítése 

a flash meghajtóra. A Fedora tartalmaz egy mkinitrd nevű 
eszközt, mely alkalmas initrd létrehozására. Sajnos cikkem 
születésekor az mkinitrd még nem volt képes titkosított 
gyökérkönyvtárat befűzni. 

A https://bugzilla.redhat.com/bugzillalshow bug.cgi?id—-1247 
89 címen elérhető folttal viszont felülkerekedhetünk ezen 

a problémán is. A folt telepítése után az mkinitrd képes lesz 
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megzsarolása vagy 
megfenyegetése 








a /etc/crypttab olvasására, illetve a megfe- 
lelő initrd létrehozására: 


1. mkinitrd -authtype-paranoid -f 
/media/usbdisk/initrd.gz 
cxrendszermagváltozat: 

2. umount /media/usbstick 


Át kell írni a /mnt/encrootletc/fstab fájlt 
is, követve a módosításokat: 


A tulajdonos 
megvesztegetése 


/dev/mapper/root / 


ext3 defaults 11 
A cseretár titkosítása vagy teljes elhagyása a titkosított fájl- 
rendszer használatának természetes velejárója. Ennek okai 

a ,litkosított saját könyvtárak megvalósítása" című cikkben 
és a BugTrag levelezési lista , Mac OS X stores login/Keychain/ 
FileVault passwords on disk" (A Mac OS X lemezen tárolja 

a bejelentkezési/ Keychain/ FileVault jelszavakat) című beszél- 
getésében találhatók meg. Ha a https://bugzilla.redhat.com/ 
bugzillalshow bug.cgi?id-127378 címről letölthető foltot 
feltesszük az initscripts csomagra, a Fedora lehetővé teszi 

a felhasználók számára, hogy véletlenszerűen létrehozott 
munkamenetkulccsokkal titkosítsák a cseretárként használt 
lemezrészt. Mivel általában a cseretárhelynek az egyes rend- 
szerindítások alkalmával nem kell megőriznie tartalmát, 

a munkamenetkulcs a rendszer leállításakor nem kerül men- 
tésre. A titkosított cseretár engedélyezéséhez a következő 
lépéseket kell végrehajtani: 
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1) A /mnt/encroot/etc/fstab fájlhoz adjuk hozzá az alábbi 
sort, lecserélve vele a korábbi swap (cseretár) bejegyzést: 
/dev/mapper/swap swap  " swap defaults 00 
2) Adjuk hozzá az alábbi sort a /mnt/encroot/etc/crypttab 
fájlhoz, ezzel közöljük a rendszerrel, hogyan kell elvé- 
geznie a titkosítást: 
swap /dev/hda3 /dev/urandom swap 
Elértünk oda, hogy újra tudjuk indítani a rendszert, és 
használatba tudjuk venni a titkosított fájlrendszert. Ismét 
tartsuk lenyomva az OPTION-COMMAND-O-F billentyűkom- 
binációt, és lépjünk be az Open Firmware parancssorába. 
Korábban már láttuk, hogy a flash meghajtó második 
lemezrészének elérési útja /pci4f2000000/usbatlb , 1/ 
diska1:2. Ennek tudatában összeállíthatjuk 
a /pci4f2000000/usbalb , 1/diskÜ1: 2, vofboot . b elérési 
útvonalat. A vessző a lemezrész számát és a fájlrendszer 
szerbéli elérési út, a v. pedig a UNIX / fájlrendszer gyökér 
jelöléséhez hasonlóan az eszköz gyökerét adja meg: 


s dir /pci(4df2000000/usbatb, 1/diska1:2,N 


untitled GMT Fi le/Dir 
Size/ date time TYPE Name 
bytes 9/ 3/ 4 21:44:41 ???? 7??? initrd.gz 

2212815 8/28/ 4  12:24:21 tbxi UNIX ofboot.b 
3060  9/ 3/ 4 2:21:20  ???? ??7?? vmlinux 
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141868 
914 
yaboot. conf 


9/28/ 4 
9/28/ 4 


12:24:22 boot UNIX yvyaboot 
12:24:22 conf UNIX 


Ezzel ellenőriztük, hogy az Open Firmware képes a rend- 
szer elindításához szükséges fájlok olvasására. Ha a boot- 
device változót a /pci4f2000000/usbatb , 1/diska1:2,N 
ofboot .b értékre állítjuk, a rendszer a flash meghajtóról 
fog indulni: 


setenv boot-device 
/pc1a4f2000000/usbátb, 1/diska1:2 , vofboot. b. 


Miután a gép sikeresen elindult a titkosított fájlrendszerről, 
semmisítsük meg a /dev/hda5 által tárolt adatokat. Erre 

a célra a gyökér fájlrendszer lemezrészének véletlenszerűsí- 
tésénél már kipróbált módszert alkalmazzuk: 


dd 1f-/dev/urandom of-/dev/hda5 


Ha gondoljuk, a felülírást többször is elvégezhetjük. A leme- 
zek tartalmának kiirtására szabványt például az Amerikai 
Védelmi Minisztérium , National Industrial Security Program 
Operating Manual" (Nemzeti ipari biztonsági program üzemel- 
tetési kézikönyve) dokumentumának 8. fejezetében találunk. 
Megfelelő törlés után a /dev/hda5 például /home könyvtár- 
ként használható. A /home fájlrendszert szintén titkosítani 
kell. Szerencsére ennek folyamata jóval egyszerűbb, hiszen 
a gép nem a /home könyvtárból indul. Magát a fájlrendszert 
a gyökér fájlrendszerhez hasonló módon hozhatjuk létre. 


1) Ellenőrizzük, hogy az aes, a dm-mod és a dm-crypt mo- 
dul be van-e töltve a rendszermagba. 


2) Válasszuk le a /home elérési út alól a titkosított kezdő- 
könyvtár-fájlrendszer tárolására kiszemelt meghajtót, 
vagyis a /dev/hda5-öt: 

$ umount /dev/hda5 

3) Hozzunk létre egy véletlenszerű, 256 bites titkosító kul- 
csot, és mentsük el /etc/home-key néven. A szükséges 


parancs. 


ff dd 1f-/dev/urandom of-/etc/home-key bs-1c 
count-32 


4) Hozzunk létre egy dm-crypt eszközt, mely az imént 
összeállított kulccsal kerül titkosításra: 


ft cryptsetup -d /etc/home-key create home /dev/hda5 


5) A /dev/mapper/home alatt hozzunk létre egy ext3 fájl- 
rendszert: 


ft mkfs.ext3 /dev/mapper/home 
6) Fűzzük be az új fájlrendszert: 


ff mount /dev/mapper/home /home 
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7) Hozzunk létre egy bejegyzést a /etc/crypttab fájlban, 
a különféle segédprogramok innen olvashatják ki a fájl- 
rendszer beállításait: 
root — /dev/hda5 /etc/home-key  cipher-aes 
8) Végül a /home könyvtárhoz tartozó bejegyzéssel bővít- 
sük a /etc/fstab fájlt: 
/dev/mapper/home /home ext3 defaults 1 2 
Szép munkát végeztünk, nekiláthatunk a további, nem root 
felhasználói fiókok hozzáadásához. A titkosított gyökér fájl- 
rendszer létrehozása befejeződött. 
Ha az összes adatunk titkosítva van, annak bizonyos veszé- 
lyei is lehetnek. Ha elveszítjük a titkosító kulcsot, vele 
együtt minden adatunk elvész. Éppen ezért ne feledjünk 
biztonsági másolatokat készíteni a kulcsot tartalmazó flash 
meghajtóról. Fontos továbbá, hogy a titkosított adatokról 
nyílt szövegű mentéseket is készítsünk. Ha rendszerindítás- 
ra alkalmas vészlemezt is összeállítunk, jól gondoljuk át, 
hogy milyen összetevőket helyezünk el rajta. A gyökér és 
a kezdőkönyvtár-fájlrendszer kulcsára mindenképpen 
szükség lesz, de nem hiányozhat a parted, a hfsutils, 
a titkosítással kapcsolatos rendszermagmodulok és 
a cryptsetup sem. 
Mennyire hatékonyan lehet ezzel a módszerrel megvédeni 
az adatokat? Secrets and Lies (Titkok és hazugságok) című 
könyvében Bruce Schneter ismertet egy olyan technikát, 
mellyel érdemi választ adhatunk erre a kérdésre. A fenye- 
getések modellezésére egy úgynevezett támadástát lehet 
használni. A 4. ábra titkosított fájlrendszerünk támadásfájá- 
nak elejét tartalmazza. Mindenképpen ki kell emelni, hogy 
ez a támadásfa nem teljes, és talán soha nem is lesz az. 
A cikkemben szereplő megoldást követve, némi kreativitás- 
sal bárki erőteljes védelemmel láthatja el adatait bizonyos 
típusú lopások ellen. Nem szabad azonban elfeledkezni 
azokról a támadástípusokról, amelyek ellen ezek a védelmi 
megoldások hatástalanok. Nyilvánvaló, hogy a hálózati és 
egyéb támadásokkal szemben más módszerekkel kell véde- 
kezni, ám az itt szereplő fogások sokban hozzájárulnak 
a rendszer általános biztonságának megalapozásához. 


Eimüx dohai 20035. janudt, 129. szám 


Mike Petullo jelenleg tesztmérnök a WMS 
Gamingnél. 1997 óta Ismeri a Linuxot. Bárki 
véleményét szívesen fogadja az IKOflyn.org 
címen. 
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Paranoid Pingvin: a Linux biztonságának 
kockázat alapú megkoözelítése 


A kockázat elkerülhetetlen. Legyünk pesszimisták a programhibákkal kap- 
csolatban, készítsünk terveket a hibák kezelésére, így egész rendszerünket 


biztonságban tudhatjuk. 


mióta négy évvel ezelőtt elkezdtem írni ezt 
AA a rovatot, a Linux program sérülékenységei 

és fenyegetései nem sokat változtak. Verem- 
túlcsordulások, hibás beállítások (fájl jogosultsági kérdé- 
seket is beleértve) nem megfelelő bemenet érvényesítés 
jelentik továbbra is a Linux sérülékenységek oroszlán- 
részét. Ha ugyanolyan típusú sérülékenységek bukkan- 
nak fel újra és újra, nem értelmetlen ez az egész folt- 
verseny? Nincs egy szélesebb látókörű Linux biztonsági 
elgondolás? 
Ebben a hónapban a Linux biztonságot kockázat alapú né- 
zőpont szerint vizsgáljuk, és bemutatjuk, hogyan használ- 
juk a kockázat alapú megközelítést az ismert Linux sérülé- 
kenységeken túl olyan problémák csillapítására, amelyeket 
még senki nem fedezett fel vagy adott közre. 





A biztonság kockázat alapú megközelítése 

Biztosan vannak akik azt kérdezik magukban, mit értek 
egyáltalán kockázat alapú megközelítésen? Hát az informá- 
ciós biztonság nem elve a kockázatról szól? Tulajdonképpen 
igen, azonban ezt a kifejezést valójában a kockázat kezelés 
alapú megközelítés rövidítéseként használom. 

Egy adott információs biztonsági kockázatot csak néhány 
módon lehet kezelni. Elkerülhetjük, azaz semmi olyat 
nem teszünk ami kitehetne bennünket a veszélynek. 
Megszüntethetjük, gyökerénél kezelve (amire sajnos 

a gyakorlatban ritkán van lehetőségünk). Enyhíthetjük, 
azaz, valami olyat csinálunk ami csökkenti a kockázat 
hatását valamilyen módon. Végül még egy lehetőségünk 
van: elfogadjuk. 

Az egyik, szerencsére mostanra elavult elgondolás szerint 

a biztonság bináris egyenlet: a dolgok vagy biztonságosak 
vagy ostobák, és ha úgy találjuk, hogy egy tevékenység 
vagy eszköz nem biztonságos, akkor azt nem szabad csinál- 
ni vagy használni. Más szavakkal ez az iskola azt hirdeti, 
hogy a biztonság elsődleges irányelve az elkerülés. 

Mint azt egyre többen felismerik manapság, tökéletes bizton- 
ság nem létezik. Nincsenek mágikus programkombinációk, 
program/rendszer összeállítások vagy hálózatszerkezet ami 
sebezhetetlenné tenne bennünket a betörésekkel szemben. 
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A helyreállítás költsége 


1. ábra Kockázati határok 


Nincs ilyen összeállítás, legalábbis olyan, amivel dolgozni 
is lehet. A hálózati számítástechnikában valamilyen szintű 
kockázat elkerülhetetlen. 

A kockázat kezelés alapú megközelítés felismerte, hogy 

a kockázat elkerülése, a kockázatcsökkentés és elfogadás kö- 
zötti egyensúlyra kell törekedni, mégpedig a kockázatokat 
fontossági sorrendbe rendezve valószínűségük és romboló 
hatásuk alapján. Csökkentés vagy elkerülés szempontjából 
a legfontosabb kockázati tényezők azok lesznek, amelyek 
nagyobb valószínűséggel következnek be és helyreállításuk 
költséges. Az erősen valószínűtlen, vagy olcsón helyreállít- 
ható hatású kockázati tényezők viszont gyakran kerülnek 
az elfogadható kategóriába. Mondanom se kell, amikor 

a kockázati tényező bekövetkezésének költségéről vagy 
hatásáról beszélek, nem kizárólag a pénzügyi költségre 
gondolok. Az időbeli és termelékenységi veszteség valamint 
a jó hírnevünk éppúgy ide tartozik. 

Az 1. ábra mutatja a kockázat valószínűsége, költsége és 
elfogadhatósága közötti általános viszonyt. Az elfogadható 
és elfogadhatatlan kockázati területeket kijelölő görbe 
pontos alakja szervezetről szervezetre változhat. 
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Egy pénzügyi cég például sokkal nagyobb vörös zónával 
rendelkezik mint egy egyetemi hálózat. A kockázat bizton- 
ság alapú megközelítése végül is annak felismerését jelen- 
ti, hogy nem minden kockázat azonos, ezért harcteret kell 
választatnunk. Azonban ahhoz, hogy ezt hatékonyan te- 
hessük meg, becsületesen és találékonyan kell beazonosí- 
tanunk és felbecsülnünk az adott vállalkozás kockázati 
tényezőit. Egy létező hiba figyelmen kívül hagyása sokkal 
veszélyesebb mint tudomásul venni és elfogadni a hibát 
és elkészíteni a visszaállítási terveket arra az esetre, ha 

a legrosszabb bekövetkezne. 

Ezzel el is érkeztünk a kockázat alapú megközelítés egy 
másik fontos tételéhez: a kockázat elfogadása még nem 
jelenti azt, hogy elégedettek lehetünk. Bármilyen kockáza- 
tot, amit nem tudunk elkerülni, vagy legalább enyhíteni, 
figyelembe kell vennünk az folyamatosság fenntartási és 
helyreállítási terveinkben. Csak nagyon kevés információs 
kockázat nem enyhíthető valamilyen mértékben; vannak 
veszélyforrások amelyek nem szüntethetőek meg, de 

a legtöbb felhígítható vagy lefékezhető. 


sérülékenységek és veszélyek 

Rendben, tehát a Linux biztonsága legjobban a kockázat 

alapú szemléletmóddal kezelhető. Hogyan is nézne ez ki? 

Az első lépés Linux rendszerünk ismert és potenciális 

sérülékenységeinek számbavétele. A legtöbb Linux alkal- 

mazás és rendszer-sérülékenység az alábbi kategóriák 

valamelyikébe esik: 

e veremtúlcsordulás sérülékenység (nem megfelelő határ 
ellenőrzés). 

e — Flégtelen bemenet hitelesítés. 

e — Helytelen fájl jogosultságok. 

e Nem megfelelő rendszer jogosultságok (felesleges root 
használat). 

e Hanyag beállítások. 

e — [deiglenes állományok nem biztonságos használata. 

e . Megjósolható vagy ismert alapértelmezett jelszavak 
alkalmazása. 

e Adminisztrációs hátsó kapuk (tesztelési és hibakeresési 
felhasználónevek). 


Valószínűleg a lista legelső sérülékenysége, a veremtúlcsor- 
dulás a legriasztóbb. A veremtúlcsordulások általában köz- 
vetlenül távoli root betöréshez vezetnek. A veremtúlcsordu- 
lás feltételeihez hasonlóan a fenti sérülékenységek egy ré- 
sze közvetlenül programozási hibák következménye. Ilyen 
például az ideiglenes állományok helytelen használata és 
adminisztrációs hátsó ajtók. Mások inkább felhasználótól 
függőek, ilyen a kiszámítható jelszó és a hanyag beállítások. 
Egyetlen sérülékenység sem jelent veszélyt, ha senki sem 
próbálja meg kihasználni azt. Más szavakkal, a fenyegetés 
két alkotóeleme a sérülékenység és a támadó. 

A második lépés végiggondolni, milyen módszerekkel 
lehet kihasználni ezeket a sérülékenységeket. Bár a Linux 
biztonsági kockázatai nem sokat változtak az elmúlt évek 
során, az őket kihasználni szándékozó szereplők mások. 
Hatékonyabbá és butábbá váltak. Az a rémisztő igazság, 
hogy a törőkódok és szkriptek könnyű elérhetősége miatt 
a képzetlen támadók is egyre könnyebben tudnak kifino- 
mult támadásokat levezényelni. 
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Engedélyezés TCP 1433," 
Engedélyezés TCP 2000465514 


Belső hálózat 


2. ábra Egyszerű tűzfal összeállítás 


Korábban például egy veremtúlcsordulás támadás leve- 
zényléséhez komoly programozási tudás kellett, ki kellett 
találni a memóriában hová kerül a túlírt adat, a támadónak 
létre kellett hozni vagy be kellett szereznie a célrendszerre 
(például 1386 vagy SPARC) jellemző assemblyben írt törőkó- 
dot vagy héjkódot. A héjkód az a kód ami majd túlcsordul 
és végrehajtódik, létrehozva egy héjat a célrendszeren, ide- 
ális esetben root jogosultságokkal. 

A régi időkben az eltolások meghatározása és működő héjkód 
megírásnak nehézségei a veremtúlcsordulás alapon támadók 
táborát erősen leszűkítette. Manapság azonban, ha ki szeret- 
nénk használni egy jól ismert veremtúlcsordulás sérülékeny- 
séget, nem kell mást tennünk mint kiadni egy jól formázott 
Google keresést, és máris megszereztük a törőkódot a hozzá 
tartozó, különféle rendszerekhez készült héjkóddokkal. 

A törőkódokat író és az interneten közreadó emberek elég 
nagy problémát jelentenek. De nem ők az egyedüli szerep- 
lői a nagy egyenletnek; aki örömét leli benne, hogy script 
kiddie-ket fegyverez fel, már nem sok választja el attól, hogy 
féregbe vagy vírusba csomagolva automatizálja törőkódját. 
A vírusok természetesen magukat nem tudják terjeszteni; 
mindig valami másba ágyazva találhatóak, például e-mail 
csatolmányban vagy végrehajtható állományokban. A fér- 
gek viszont magukat terjesztik, így lényegesen félelmete- 
sebbek, hiszen tulajdonképpen szárnyas vírusok. Ha fé- 
regtámadás idején a naplóbejegyzéseket nézzük, nagyon 
nehéz megkülönböztetni őket egy ember vezérelte táma- 
dástól. A féreg tulajdonképpen egy támadó robot. 

Így a támadó lehet ember és lehet program. A jó hír, 

hogy mivel a ugyanolyan típusú sérülékenységet támad- 
nak, a védekezés is hasonló. A rossz hír, hogy a támadó 
szkriptek férgek és vírusok exponenciális mértékben csök- 
kentik a sérülékenység felfedezése és közzététele, valamint 
a rendszerünk valószínűsíthető megtámadása közötti időt. 


Első védelmi megoldás: Túzfal rendszabályok 

Kezdjük el ezeket a fenyegetéseket a megfelelő védelem- 
hez rendelni. Itt kezd majd a kockázat alapú megközelítés 
igazán fontossá válni. 


Amennyiben mindent vagy semmit alapon tekintünk a biz- 

tonsági kérdésekre, a védelem egyszerű. A programokat 

nem képességeik, támogatottságuk és biztonságosságuk 

összesítése alapján, hanem tisztán a biztonságosságuk sze- 

rint válogatjuk. Minthogy a fő programfeltételünk a bizton- 

ság egyetlen dologra kell figyelnünk, nevezetesen a folto- 

zásra, és minden rendben lesz. 

Elképzelhető, hogy úgy állítjuk be a tűzfalunkat, hogy semmi- 

lyen kívülről jövő kapcsolatban se bízzon, de fogadjon el min- 

den belülről érkezőt, hiszen, természetesen minden külsős 

gyanús és minden belső megbízható. Ami azt illeti, a program- 

foltok és tűzfalszabályok olyannyira fontosak ebben az elkép- 

zelésben, hogy tulajdonképpen semmi más nem számít. 

A program foltok és tűzfal szabályok tényleg nagyon fonto- 

sak. Azonban a programfoltoktól való függésünk foka és 

tűzfalhasználatunk mikéntje egy kicsit eltérő lehet, ha 

vesszük magunknak a fáradtságot és meggondoljuk mi- 

lyen valós fenyegetéstől óvnak bennünket. Képzeljük el 

a 2. ábrán felvázolt helyzetet. A tűzfal a DMZ hálózatot 

védi a külső világtól, az pedig a belső hálózatot védi a külső 

világtól és a DMZ-től. 

A 2. ábrán pontozott vonallal jelölt tűzfal szabályok a követ- 

kezőképpen nézhetnek ki: 

1. Az összes belső gép elérheti az Internetet bármelyik 
kapu/protokoll párossal. 

2. Az DMZ gépnek engedélyezzük az Internet elérést 
bármely kapun/protokollon. 

3. Az összes internet gép elérheti a DMZ-t a 80-as ICP 
kapunk keresztül (HTIP). 


4. A DMZ webkiszolgálója elérheti a belső gépeket a 1433 
és 2000-65514 közötti TCP kapukon. 


Elsőre egész jónak tűnik. A belső felhasználók mindenfé- 
le dolgokat csinálnak az Interneten, így ezt korlátozni 
zűrös lenne. A naplók miatt a DMZ DNS lekérdezéseket 
végez, szóval miért ne adnánk Internet elérést neki is? 
Van ezen felül egy háttéralkalmazás amit a DMZ-be tett 
webkiszolgálónak el kell tudni érnie a belső hálózaton 
és ahol adatbázis lekérdezéseket adhatunk ki a 1433-as 
TCP kapun valamint egy véletlenszerűen választott 
magas kapun ami egy olyan véges tartományba esik, 
amit senkinek nem sikerült dokumentálnia. Ezért aztán 
a legegyszerűbb ha megnyitjuk az összes 1999-nél maga- 
sabb ICP kaput. 

De nézzünk három kézenfekvő kockázati tényezőt: 

1. Az internet alapú támadó feltöri a webkiszolgálót és 
más gépeket támad vele az interneten. 

2. Egyik belső gépet féreg fertőzi meg valamilyen RPC 
sérülékenységen keresztül, és a fertőzött rendszer hatal- 
mas mezőket kezd pásztázni az interneten más sérülé- 
keny rendszereket kutatva. 

3. Egy féreg megfertőzi a belső rendszert és hátsó kaput 
nyit a 6666-os ICP kapun. A támadó feltöri a webki- 
szolgálót, letapogatja a tűzfalat, felderíti a jól ismert 
féreg ajtót és belép a belső rendszerbe. 


Az első kockázati kérdésben egyértelműen jogi problémák- 
nak tesszük ki magunkat. Ha a webkiszolgálót feltörik és 
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a tűzfalunk nem akadályozza meg rajta keresztül a külső 
világ elérését, felelősnek érezhetjük magunkat, hiszen a mi 
rendszerünkről támadnak más rendszereket az interneten. 
A webkiszolgáló kimenő elérését a legszükségesebb szolgál- 
tatásokra korlátozva csökkenthetjük a kockázatot. A gya- 
korlatban egy DMZ-be helyezett webkiszolgálónak nagyon 
kevés adatfolyamra van szüksége a külső világ felé, ha 
szüksége van egyáltalán ilyesmire. Az a feladata, hogy az 
internetről érkező HTTP lekérdezésekre válaszoljon, nem 
pedig, hogy maga kezdeményezzen kapcsolatokat. 

A második forgatókönyv szerint hasonló problémáknak 
tesszük ki magunkat, de itt a jogi következményeknél ko- 
molyabb gondot okoz a dolog hálózati teljesítmény oldala 
(a pásztázás forgalma eldugíthatja az Internetes kapcsola- 
tunkat). Akárcsak az előbb, egy szigorúbb tűzfal rendszabály 
a kimenő forgalomra egyértelműen csökkenti a kockázatot. 
A harmadik forgatókönyv egy kicsit szokatlanabb mint 

a többiek, végül is mennyi az esélye, hogy egy féreg meg- 
fertőzze a belső rendszert és egyúttal a DMZ-ben található 
webkiszolgálónkat is feltörjék? Nos, tulajdonképpen a ket- 
tőnek nem kell egyszerre bekövetkeznie. Ha a féreg csend- 
ben marad miután elkészíti a hátsó ajtót a 6666-os ICP ka- 
pun, jó ideig nem fogjuk felfedezni. Ilehát a webkiszolgáló 
feltörése nem kell, hogy aznap vagy akár abban a hónap- 
ban történjen, hiszen a féreg munkáját a fertőzött rendszer- 
ben nem hatástalanítottuk elég hamar. Akárcsak az előző 
két forgatókönyvben, egy szigorúbb rendszabály csökkent- 
heti a kockázatot és minimalizálja annak az esélyét, hogy 

a féregfertőzést külsősök ki tudják használni. 

Azon felül, hogy szigorúbb szabályokkal veszélyességük 
csökkenthető, e három veszélyforrásnak van még egy közös 
jellemzője. Csökkentésükhöz nem kell pontosan megjósol- 
ni őket. Elég ha csak arra gondolunk ,mi van ha a tűzfal 
szabályaim ellenére valamilyen féreg vagy vírus bejön, 

és váratlan típusú kimenő forgalmat kísérelnek meg?" 

Nem tudom eléggé hangsúlyozni, nagyon fontos, hogy 

a tűzfal szabályok készítésekor ne csak a támadások 
megelőzésére koncentráljunk. Legalább ilyen fontos, 

hogy végiggondoljuk, mi történik ha a védelmünk cső- 

döt mond. Az információs biztonság terén a pesszimizmus 
épít és nem rombol. 

Remélem mostanra világossá vált, hogy véleményem sze- 
rint nem a tűzfal szabályok adnak választ az összes Linux 
biztonsági kérdésünkre. Összefoglalva, hatékony tűzfal 
szabályokat akkor tudunk készíteni, ha nem csak az ismert 
fenyegetéseket, hanem a lehetséges fenyegetéseket is figye- 
lembe vesszük. 


Második védelmi megoldás: az alkalmazások biztonsága 
Nos, ha a tűzfal nem csodaszer, akkor mit tehetünk? A ro- 
vatban korábban a hanyag beállításokat az egyik legna- 
gyobb sérülékenységi forrásnak neveztem; ezt megfordítva, 
a figyelmes beállítás az egyik legjobb védelem. 

legyük fel, a DMZ-ben van egy SMTP átjáró ami az 
Internet és a belső hálózat közötti levelezést bonyolítja. 
legyük fel továbbá, hogy a szervezetünk műszaki sze- 
mélyzetének nagy tapasztalata van a Sendmaii terén, vi- 
szont se idejük, se hajlandóságuk megtanulni a Postfix 
használatát, amit egyébként mint megrögzött biztonság- 
mániás, sokkal biztonságosabbnak tartok. A vezetés úgy 
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dönt az átjáró Sendmailt fog futtatni. Minden elveszett? 
Nem szükségszerűen. Először is, mint azt a rovatban koráb- 
ban is említettem, a Sendmail biztonsági mutatói tulajdon- 
képpen egészen jók lettek az utóbbi években. Azonban, 

ha mindez meg is változik egyetlen éjszaka alatt, és a rossz 
fiúk három újabb veremtúlcsordulás hibát találnak a Send- 
mailben amit nem adnak közre azonnal, a Sendmail fejlesz- 
tők egészséges pesszimizmusának hála, Sendmail átjárónk 
még nem bukott el feltétlenül. 

A Sendmail-nek van néhány fontos biztonsági képessége, 
amiből kettő különösen hasznos lehet veremtúlcsordulások 
esetén. A Sendmaiil futhat chroot ketrecben, ami korlátozza 
a látható fájlrendszer területet, valamint előjogok nélküli 
felhasználó és csoportjogosultságokkal is indítható, így mi- 
nimalizálhatjuk annak az esélyét, hogy a Sendmaiil sérülé- 
kenység közvetlenül root eléréshez vezessen. Minthogy 

a Sendmail a kivételezett 25-ös TCP kapura hallgat, legalább 
az idő egy részében rootként kell futnia, ezért a Sendmail 
gyakorlatilag időnként lefokozza saját magát különleges 
jogosultság nélküli felhasználó/csoport szintre. Ez tehát az 
enyhítés nem teljes, csak részleges. 

Manapság a legtöbb jól tervezett hálózati alkalmazás 
chroot-olható és futtatható előjogok nélküli felhasználó/cso- 
port jogosultságokkal. Ahogy a jó tűzfal szabály egyszerre 
célozza a megelőzést és a behatárolást, a helyes alkalmazás 
beállításkor is számításba kell venni, hogy az alkalmazással 
visszaélhetnek vagy eltéríthetik. Ezért aztán az alkalmazás 
biztosíthatóságát nem csak az méri hány CERT tanácsadó- 
ban szerepel. Az alkalmazásnak rendelkeznie kell beépített 
mérséklési lehetőségekkel is. 


Osszefoglalás 

A biztonság kockázat alapú megközelítése két fontos 
előnyt jelent számunkra. Először is, ahelyett, hogy egy- 
folytában nemet mondunk mindenre, az ilyen megközelí- 
tést gyakorló biztonsági szakemberek inkább az , igen, ha" 
kifejezést használhatják (azaz , igen, használhatjuk az 
eszközt, ha lecsökkentjük X veszélyét, visszatartjuk Y 
veszélyt" és így tovább). Másodsorban, azáltal, hogy 

nem csak az ismert veszélyforrásokra koncentrálunk, 
hanem általánosabb kockázatokat is figyelembe veszünk, 
a kockázat alapú megközelítés mélyebb védelmet tesz 
lehetővé, ahol a réteges vezérlés csökkenti az esélyét, 
hogy egyetlen fenyegetésnek globális következményei 
legyenek (tűzfal szabályok a chroot-olt alkalmazásokkal 
valamint behatolásjelző rendszerek használata és egyéb 
módszerek). 

Remélem sikerült hasznos leírást készíteni, ami talán kicsit 
jobb rálátást ad a rovatunkban felbukkanó más, , inkább 
drótelvű" biztonsági eszközökre és módszerekre is. 
Csak biztonságosan! 
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NMaia Mailguard és amavisd-new a Spam levelek 


és a virusok réme 


Úgy érzi nem engedheti meg magának, hogy vállalkozása vezető spam és vírus- 
védelmet használjon? Két jó indok, amiért érdemes ezt újragondolni. 


anapság ahogy a spam és e-mail férgek egyre 
terjednek, eljött az anti-spam és anti-vírus meg- 
oldások szállítóinak aranykora. Az Európában és 
az USA-ban bevezetett anti-spam törvények nem túl sok 
eredményt értek el, így az áldatlan állapotok sok embert 
késztettek technikai megoldások, spam és vírus szűrők 





vásárlására. 

A tartalom szűrése minden egyes gépen ugyanakkor meg- 
lehetősen drága és nem is túl praktikus megoldás. Ideális 
esetben a spam és vírus problémákat gyökerüknél kell 
kezelni, így e pont mögött mindenkit megvédhetünk. 

Ezt a stratégiát követő szervezeteket minden erőforrásukat 
egyetlen helyre összpontosítják, mégpedig általában a leve- 
lező kiszolgálóra. 

A kiszolgáló alapú megoldások azonban ritkán olcsók. 

A legtöbb ilyen termék esetében levelesládánként kell fizet- 
ni, legyen szó levelezőkiszolgáló bővítményről vagy önálló 
tartalomszűrő alkalmazásról. Ezek a megoldások dollár- 
ezrekbe is kerülhetnek és gyakran a vírus- és spam-minták 
frissítéseiért is éves díjat szednek. 

Ebben a cikkben az amavisd-new nyílt forráskódú tartalom- 
szűrő rendszerrel ismerkedhetünk meg, valamint a projekt 
egyik hatékony kiegészítésével a Maia Mailguard-dal. 


amavisd-new 

Az amavisd-new lényegében levelező-szűrő - leveleket 
fogad a levelezőkiszolgálótól, megállapítja hogy tartalmaz- 
nak-e spam-et vagy vírusokat, majd ennek megfelelően 
karanténba helyezi, elutasítja vagy kidobja a szabálysértő 
elemeket végül a maradékot a kézbesítést végző másik 
levelezőkiszolgálóra irányítja. Gyakorlatban az amavisd- 
new gyakran található két azonos gépen futó levelezőki- 
szolgáló között, hiszen, különösen a kisebb helyek eseté- 
ben, a levelezőkiszolgálót és a tartalomszűrőt praktikus 
lehet azonos gépen elhelyezni. A nagyobb helyek külön 
tartalomszűrő gépre telepíthetik az amavisd-new, 
SpamáAssassin és vírusirtó programjaikat. Még nagyobb 
helyeken ilyen gépek terheléseloszlásos hálózatát érde- 
mes felépíteni. 

Az amavisd-new Perl nyelven, a biztonságot és megbízható- 
ságot szem előtt tartva készült és lényegében minden UNIX 
rendszeren jól üzemel. Magja az RFC-nek megfelelő levél- 
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kezelő, amelyet úgy terveztek, hogy soha ne veszítsen el 
egyetlen levelet sem. Ennek érdekében az amavisd-new 
mindaddig nem veszi át véglegesen a levélelemet amíg az 
alatt elhelyezkedő levelező kiszolgáló át nem veszi tőle azt. 
Ez annyit jelent, hogy ha bármilyen hiba történik a levél 
szűrése közben, a levél nem veszik el, hiszen a felső 
levelezőkiszolgáló sorában megmarad. Az amavisd-new 
négyféle szűrési lehetőséget kínál: virus/malware kere- 

sés, spam szűrés, veszélyes csatolmányok és érvénytelen 
fejlécek tiltása. 


Víruskeresés 

Az amavisd-new nem víruskereső; inkább egy keretrend- 
szer, amely egy vagy több víruskereső meghívására képes. 
löbb mint 30 népszerű víruskeresőt támogat többek között 
olyan üzleti termékeket is mint a Sophos, Symantec és 
Network Associates, és persze a nyílt forráskódú Clam 
Antivirus-t. 

A parancssoros és démon-alapú víruskeresők egyaránt tá- 
mogatottak. Persze a démon alapú keresők sokkal hatéko- 
nyabbak mint parancssoros rokonaik. Amennyiben a leve- 
lezőkiszolgálónk nagy mennyiségű levelet dolgoz fel, nem 
valószínű, hogy szívesen töltenénk be a memóriába egy pa- 
rancssoros víruskeresőt minden egyes levélhez, amit aztán 
eltávolítunk onnan. A démon alapon futó víruskeresők csak 
egyszer töltődnek be, végig a memóriában maradnak, így 
az egész folyamat sokkal gyorsabb. 

Amennyiben több víruskeresőnk is van, elsődleges és má- 
sodlagos csoportokba sorolhatjuk őket. A másodlagos cso- 
porthoz akkor nyúl a rendszer, ha egyik elsődleges kereső 
sem érhető el. 


Spam szűrés 

Az amavisd-new a spamszűrést a SpamAssassin beépítésé- 
vel végzi. Az amavisd-new a címzettek számától függetlenül 
minden egyes levélhez egyszer hívja meg a SpamAssassint, 
így a levelezőlisták vizsgálata sem foglal több erőforrást 
mint az egy címzettel rendelkező levelek. 

A SpamAssassin a spamszűrő módszerek széles skáláját 
vonultatja fel: képes jellegfelismerésre, DNSBL és SPF kere- 
sésre, kezeli a együttműködésen alapuló jelentési hálózatokat 
(collaborative reporting networks) és a Bayes-féle tanuló 
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1. ábra Minden e-mail cím saját tartalomszűrő 
beállításokkal rendelkezik 
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2. ábra A felhasználók saját fehér- és feketelistákat tarthatnak fenn 
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3. ábra A rendszergazda a legtöbb teljes körű beállítást elérheti 
a webes felületről 


módszert. Minden teszt megállapít valamilyen számszerű 
értéket, amelyet aztán levelenként összegezünk, a felhasz- 
nálók pedig tetszőleges határértéket állíthatnak be, ezáltal 
eldöntve, hogy mit tekintenek spam-nek és ham-nek. 

(A ,ham" szó spamszűrő körökben a nem-spam levelet 
jelenti azaz a spam ellentéte, a Monty Python féle spam 
(löncshús) mintájára. a fordító) Ez elég hatékony megoldás, 
hiszen az egyik módszer gyengéit a többi módszer javítja. 
A jellegfelismerő a levél fejlécét és a levéltestét vizsgál- 
ja olyan nyomok után kutatva, melyeket az emberek 
spam vagy ham (nem-spam levél) jellegzetességeknek 
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Maia Mailguard 


4. ábra A szűrők által látottakat statisztikák 
foglalják össze 


Maia Mailguard 


User: ismith 


TESTEKTERENEL TES VZESESEZESEONNTEESEZEB JESESESZTNGSEBESB TESSENEK ÉGBE EST EEEEZEZEZEE ANG EGEN 
2004-02-20 23:55:20  spammer1Gexample.com  jsmithgexample.com No Hassles or Embarrasment order from us 


EwWD: Available All. alium. " v[0gRa 
2004-02-20 23:37:24 spammerz€gexample.com jsmithaexample.com SE STT ÉGETT 


KÖZÖSBESZETEEONNSKÁNGAN 
2004-O2-20 23:.46:24  spammer3üexample.com jsmithaexample.com xantatx ?F lOricst " Pnt/e/rmin 2 
Somtat OvByf 
"1 — 2004-02-21 00:09:18 spammer4Gexample.com jsmithüexample.com Yysirambb Our team is ready 
2004-02-20 23:55:06 . spammers€rexample com ALTÉKNÉSESGIT EEEN] JN-ÉSÍNOK-ADLOIOÉ DÁK NATO ATÚDAK 


5. ábra A felhasználói karantén a spam-pontszám szerint rendezett 


tartanak. Az a tény például, hogy a levél Date: fejléce 

12 órával a jövőbe mutat vagy, hogy a levél szöveget 
nem, csak képet tartalmaz, könnyen utalhat spam jelen- 
létére, míg egy több mint ezer szót tartalmazó levél való- 
színűsíthetően ham. 

A Spamássassin képes ellenőrizni a csatlakozó levelező- 
kiszolgáló vagy ügyfél IP címét, majd ellenőrizni szerepel-e 
valamelyik DNS-alapú tiltólistán (DNSBL), így képes meg- 
határozni, hogy a küldő esetleg ismert spam forrás. 

A DNSBL listák hagyományos alkalmazásával szemben 
azonban a SpamAssassin nem feltételezi, hogy a listán való 
szereplés önmagában végzetes bizonyíték; egyszerűen csak 
megnöveli a levél teljes pontszámát. Ez sokkal rugalmasabb 
megközelítés és lehetőséget ad arra, hogy külön beállítsuk 
valamennyi DNSBL pontszámát, attól függően mennyire 
bízunk meg listában és karbantartóinak rendszabályaiban. 
A hamarosan megjelenő SpamAssassin 3.0 már támogatja 

a Sender Policy Framework (SPP) kereséseket, amely meg- 
próbálja azonosítani, hogy a kapcsolódó gépnek van e joga 
levelet küldeni az adott tartomány neve alatt. 

Az együttműködésen alapuló jelentési hálózatok, mint 

a Vipul Razor-ja, Pyzor és a Distributed Checksum 
Clearinghouse (DCC) egy másik tájékozódási forrást kínál- 
nak a SpamAssassin részére. Az alapötlet az, hogy miután 

a spam leveleket fogadók millióinak küldik el, mire meg- 
kapjuk a nekünk szólót, rengeteg ember kap többé kevésbé 
hasonló leveleket. Amennyiben elég sok ember jelezte hogy 
az adott levél spam a mi spamszűrőtk is felhasználhatja ezt 
a tényt saját döntésfolyamatában. 

Végül, de természetesen nem utolsósorban, a SpamAssassin 
Bayes-féle tanuló mechanizmust is tartalmaz, amely lénye- 
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PYZOR CHECK Listed in Pyzor (http.//pyzor.sf.net/ 
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Received via a relay in li 
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HTML MESSAGE HTML induded in messagé 
"Spammer" cspammeríüexample.com: 
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CONTENT-TYPE: multipart/alternative 


CONTENT-TYPE: text/plain 
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6. ábra A levélnézegetővel biztonságosan megvizsgálhatjuk 
a gyanús leveleket 


gében automatizált jellegfelismerő. Míg a korábban ismer- 
tetett jellegfelismerő rendszer az emberekre bízza a spam 
és ham közötti felismerhető különbségek azonosítását, 

a Bayesian megközelítés magától próbálja meg felderíteni 
ezeket a jellegzetességeket a korábban kapott spam és ham 
levelek vizsgálata alapján. 


Veszélyes csatolmánytípusok tiltása 

Üzembiztossági megfontolásokból gyakran jó ötlet megaka- 
dályozni a végrehajtható csatolmányokkal érkező leveleket, 
még ha a víruskeresőink szerint tiszták is. Végül is a vírus- 
keresők sem tökéletesek, ráadásul a legfrissebb gonoszsá- 
gok könnyen elérhetik a rendszerünket még mielőtt az anti 
vírus forgalmazó elkészítené a felderítéséhez szükséges új 
vírusmintát. Az amavisd-new lehetővé teszi, hogy megad- 
junk fájlkiterjesztés listákat, tartalomosztályokat és MIME- 
típusokat, amelyeket karanténba szeretnénk zárni, elutasí- 
tunk vagy törölni kívánunk. 


Ervénytelen levélfejlécek kezelése 

Az REC 2822 szabvány szerint, a levélfejlécekben nem sze- 
repelhet semmilyen 127-nél nagyobb értékű karakter, NULL 
vagy önmagában álló soremelés. Ezen a tartományon kívüli 
karakterek különleges kódolásúak lehetnek, így a világ kü- 
lönféle levelezőprogramjai probléma nélkül tudják értel- 
mezni őket. Ha érvénytelen fejléccel érkező levelet kapunk, 
az lehet egy gyengén megírt levelezőügyfél hibája is, de 
igen gyakran olyan egyedi tervezésű program terméke, 
amilyeneket a spammerek használnak a tömeges levelezés- 
hez. Az ilyesfajta, úgynevezett ratware (rat— patkány) készí- 
tői általában angol anyanyelvűek, és többnyire nem is gon- 
dolnak rá, hogy programjukat más nyelveken beszélők is 
használni fogják. Amikor a spammerek megpróbálják ezek- 
kel a programokkal elküldeni a leveleiket, a ratware nem 
kódolja a különleges karaktereket, így hibás levélfejléceket 
készít. Az amavisd-new programban eldönthetjük, mit kí- 
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7. ábra A ham gyorstár segítségével a felhasználó egyszerűen 
jelezheti az átcsúszott elemeket 


E Lf 


vánunk tenni az érvénytelen fejlécű levelekkel: karanténba 
zárjuk, elutasítjuk, elvetjük, vagy keresztülengedjük. 


Tartalomszűró házirend beállítása 

Az amavisd-new segítségével a rendszergazdák rendszer 
szintű tartalomszűrő rendszabályokat készíthetnek, ám 
ezeket a szabályokat tartomány illetve felhasználói szinten 
felülbírálhatjuk. Vannak felhasználók akik szeretnék átvizs- 
gáltatni leveleiket mind a négy gyanús tartalomtípus (víru- 
sok, spam, tiltott fájlok és érvénytelen fejlécek) szerint, má- 
sok viszont inkább kikapcsolnák valamelyik vagy akár vala- 
mennyi ellenőrzést. Az egyik felhasználó szeretné, ha az 5.0 
vagy ennél nagyobb értéket elérő levelei a karanténba ke- 
rülnének, míg mások inkább azt részesítenék előnyben, 

ha a Subject: fejléc bővülne egy speciális előtaggal (például 
tSSSPAM"""), amennyiben a pontszám eléri a 4.0-t és csak 
akkor blokkolnák, ha 8.0-at is meghaladja. Ez a fajta finom 
felbontású vezérlés a teljes szűrőfolyamat alatt lehetővé te- 
szi, hogy a rendszergazdák eltérő igényekkel rendelkező 
felhasználók széles körét szolgálják ki. 

Ezen felül az amavisd-new mindhárom szinten fehér és fe- 
ketelistákat tárol. Ezáltal a rendszergazdák rendszerszintű 
listákat hozhatnak létre; míg a rendszer másik végén a fel- 


használók saját egyedi listákat hozhatnak létre. 


Karantén és figyelmeztetési lehetőségek 

Előre meghatározhatjuk milyen lépéseket végezzen el 

az amavisd-new amikor megállít egy e-levelet. A levelet 
tárolhatjuk a karantén könyvtárban vagy levelesládában, 
vagy akár felhasználónkénti külön levelesládákban 

(pl. jozsit spam). Választhatjuk az is, hogy az amavisd-new 
utasítsa el a levelet, azaz vagy ne fogadja el a felette elhe- 
lyezkedő kiszolgálótól vagy csendben dobja ki azt. 
Amennyiben a szervezeti szabályzatunk előírja, hogy a fel- 
használókat figyelmeztetni kell a blokkolt levelekkel kap- 
csolatban, az amavisd-new-ban ez is beállítható. Ez azonban 
vitatott téma. Manapság sok ember a vírusfigyelmeztetése- 
ket és spam reklamációkat inkább idegesítőnek mint hasz- 
nosnak tartja , különösen amióta a levelek feladója általá- 
ban hamisított. Amennyiben mégis kellene küldenünk ví- 
rusfigyelmeztetéseket, az amavisd-new tartalmaz egy listát 
azokról a vírusokról, amelyek bizonyítottan meghamisítják 
a levélfejléceket így ilyenkor nem küld figyelmeztetéseket 
sem. Ezt a listát kézzel kell karbantartanunk és meg kell 
egyeznie azokkal a nevekkel, melyet az általunk használt 
víruskereső visszaad. Amennyiben egyszerűbbnek találjuk 
felsorolni azokat a vírusokat, amelyek nem hamisítanak 
címet, használhatunk inverz listát is. 
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Maia Mailguard 

A Maia Mailguard egyszerű amavisd-new webes felületként 
született pályafutását, amely lehetővé teszi a felhasználók- 
nak, hogy egy kényelmes felületen keresztül változtassák 
meg tartalomszűrő beállításaikat és kezeljék karanténjüket. 
A projekt egyre népszerűbb lett az ISP-k, Web-mail 
szolgáltatók és a lapon kívüli szűrést kínáló cégek köré- 
ben, így ezek a nagyobb igényű felhasználók hatására 

a Maia Mailguard hamarosan sokkal kifinomultabb 
rendszerré alakult. 

A Maia Mailguard teljes értékű spam és vírus kezelő rend- 
szer, amely PHP, SOL és Perl parancsfájlokat, MySOL vagy 
PostgreSOL adatbázist valamint természetesen az amavisd- 
new, SpamAssassin rendszert és egyéb támogatott víruske- 
resőket tartalmazhatja. Több lartalomszűrő kezelhető 
egyetlen Maia csatolófelületről, amelyek egyazon SOL 
adatbázison osztoznak. lekintve, hogy a tartalomkezelés, 

a karantén karbantartás és spamjelentések leegyszerűsítésé- 
re tervezték, a Maia Mailguard sok szempontból új eszköz 
a levelező felhasználók kezében. 


Webes felület 

A Maia web-alapú felülete több forrás szerinti azonosítást 
is lehetővé tesz, használhatunk POP3 vagy IMAP kiszolgá- 
lót, LDAP kiszolgálót, külső SOL adatbázist vagy a Maia 
saját belső adatbázisát. A felhasználókat a rendszergazda 
felveheti kézzel vagy is felkerülhetnek amikor olyan levél 
érkezik helyi címre melynek címzettjével a Maia még nem 
találkozott azelőtt. 

A felhasználóknak több e-mail címe is tartozhat egyet- 
len azonosítóhoz, de minden e-mail cím saját tartalom- 
szűrő beállítással rendelkezik (1. ábra). A felhasználók 

a webfelületen keresztül címeket adhatnak hozzá és távo- 
líthatnak el a fehér- illetve feketelistáikról (2. ábra), míg 

a rendszergazdák egy másik weblapkészleten tartomány 
illetve rendszer szintű beállításokat módosíthatják (3. áb- 
ra). Az amavisd-new mind a négy levéltípusáról statiszti- 
kák készülnek, nem különben a fehér- és feketelistára ke- 
rülő elemekről, túlméretes elemekről, hamis találatokról 
(false positives) és átcsúszásokról (false negatives) (4. ábra). 
Más táblázatok típusonként nyomon követik az egyes ví- 
rusokat valamint azt is, hogy mely SpamAssassin szabály 
hány alkalommal aktiválódott. Az adatokból valós időben 
grafikus ábrák készíthetők vagy adott időközönként stati- 
kus lapként elmenthetők. 

Annak köszönhetően, hogy a Maia a karanténkezelést 

és a tartalomszűrő vezérlést egyenesen a felhasználók 
kezébe helyezi, a rendszergazdáknak nem sok naponta 
elvégezendő munkájuk marad. A Maia adott időben le- 
futó Perl parancsfájljaival kiegészítve, melyek jelentik 

a felhasználók által jóváhagyott spam leveleket és keze- 
lik a lejárt karantén elemeket, a rendszer szinte önmagát 
működteti. 


Karanténkezelés 

Felhasználói szemszögből igen fontos, hogy amikor egy levél 
a karanténba kerül, könnyedén el tudjuk érni azt. A Maia 

a felhasználói karanténjában megtekinthetjük az elemek lis- 
táját, mégpedig spam pontszám szerint rendezve. lehát azok 
az elemek amelyek a legnagyobb valószínűséggel tévedésből 
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kerültek ide — azaz a hamis találatok -— a lista tetején foglal- 
nak helyet, így könnyebb észrevenni őket (5. ábra). 
Amennyiben a fejléc alapján nem tudjuk eldönteni, hogy 
egy levél kívánatos-e vagy sem, a címre kattintva megte- 
kinthetjük azt a Maia levélnézegetőjében (6. ábra). A levél- 
nézegetőt bármilyen típusú levélen biztonságosan használ- 
hatjuk, ugyanis a legtöbb csatolmányt nem dekódolja, 
viszont letiltja a távoli képeket és kiszedi azokat a HIML 
tagokat amelyek más lapra irányíthatnának át bennünket. 
A levelet dekódolt vagy nyers formában is megtekinthetjük, 
valamennyi eredeti levélfejléccel együtt. 

Amennyiben úgy döntünk, hogy a levél végül mégiscsak 
kívánatos, egy kattintással kimenthetjük a karanténból és 
elküldhetjük magunknak. Ezzel egy időben a Maia értesíti 
a SpamAssassin-t a hibáról, így a Bayesian tanulórendszer 
kisebb valószínűséggel követi el még egyszer ugyanezt 

a hibát. A Maia-t úgy is beállíthatjuk, hogy az ilyesfajta ki- 
menekítések esetén a küldő címét automatikusan felvegye 
saját fehér listánkra. 

A karanténon kívül a Maia rendelkezik egy úgynevezett ham 
gyorstárral is, amelyben tulajdonképpen a mostanában ka- 
pott elfogadott leveleink találhatók (7. ábra). A ham gyorstár 
célja, hogy könnyedén jelenthessük a szűrőn átcsúszott spam 
leveleket (false negatives). Ezeket az elemeket helyesen spam- 
nek kijelölve taníthatjuk a SpamAssassin Bayes-féle szűrőjét. 
A karantén és a ham gyorstár egyaránt a kapott levelek ál- 
lapotának hitelesítésre szolgál. Ezzel nem csak a Bayes-féle 
tanuló rendszert oktatjuk, hanem egyúttal lehetővé tesszük 
a spam levelek helyes beazonosítását is, hiszen az intézke- 
dést ember hagyja jóvá. 


Spam jelentés 

A legtöbb spamszűrő csak a spam támadások kivédésre 
koncentrál és nem sokat, vagy egyáltalán nem törődik azok 
megelőzésével. Minthogy a Maia lehetővé teszi felhasználó- 
inak, hogy spam-ként azonosítsák a leveleiket miközben az 
eredeti levélfejléceket nem módosítja, a spam több különféle 
módon is jelenthető. A Maia következő verziói képesek lesz- 
nek részletes fejlécanalízist végezni és félautomata jelentése- 
ket küldeni az ISP-k részére. Ezek a jelentések segítenek 
másoknak hatékonyabban kiszűrni a spam leveleket végül 
egyfajta büntetést jelenthetnek a spammelő számára. 

A színfalak mögött a Maia automatikus parancsfájljai sza- 
bályos időközönként feldolgozzák a karantént, jelentik 

a helybenhagyott spam leveleket a SpamAssassin által hasz- 
nált együttműködésen alapuló hálózatoknak (Vipul"s Razor, 
Pyzor és DCC). Azzal, hogy megosztjuk az információt 
ezekkel a hálózatokkal, valamit adunk is és nem csak nye- 
rünk mások jelentéseiből. 


Hatékony, teljes körű megoldás 

Végül, szóljunk pár szót arról ami a leginkább számít, vajon 
mennyire hatékony az amavisd-new és a Maia Mailguard 

a spam levelek elfogása terén, és milyen eséllyel kerülik el 
ham leveleink a karanténba kerülést? Saját helyem statiszti- 
káiból ollózva, ez az érték szimpatikus 99.229 , 0.2690 ha- 
mis találati (false positive) és 0.529 átcsúszó levél (false 
negative) értékkel. Ami a legjobb, ezeket a hamis találatokat 
könnyedén kigyűjthetjük a karanténból míg az átcsúszott 
leveleket jelenthetjük a ham gyorstárban. 





A vírusok és egyéb rossz szándékú küldemények terén 

a hatékonyság még figyelemreméltóbb: 10095. Az alatt a hat 
hónap alatt amióta ezt a tartalomszűrő megoldást telepítet- 
tem, az asztali gépekre feltett víruskeresők semmit sem fog- 
tak ami átcsúszott volna a tartalomszűrőn. Persze ebben 
nagy szerepe van annak is, hogy az amavisd-new több elté- 
rő gyártótól származó víruskereső együttes használatát is 
lehetővé teszi — amit az egyik kereső elhibáz a másik általá- 
ban elkapja. 

Ha a teljesítményt nézzük, minden tartalomszűrő megoldás 
lelassítja valamilyen mértékben a levélfeldolgozást. Gyak- 
ran előfordul, hogy a nagyobb sebesség érdekében enged- 
ményeket teszünk a szűrő hatékonyság rovására, és inkább 
kikapcsolunk néhány szűrőt és tesztet ezzel növelve az át- 
viteli teljesítményt. A nálam mért 99.2290-os hatékonyság 
eléréséhez például valamennyi szűrő bekapcsolt állapotban 
volt, ennek megfelelően 1-3 másodpercre volt szükség min- 
den egyes levélelem átvizsgálásához egy közepesen terhelt 
dual-PIII 733MHZz-es gépen IGB memória mellett. Egy el- 
foglaltabb helyen elképzelhető, hogy ekkora késlekedés 
már nem elfogadható. Ők vagy kikapcsolják az időigénye- 
sebb teszteket, vagy gyorsabb processzort és több RAM-ot 
vásárolnak a tartalomszűrőhöz esetleg terheléselosztáson 
alapuló hálózatot építenek több tartalomszűrőből. Ettől 
függetlenül több mint 50.000 felhasználónak helyet adó 
rendszerek is használnak Maia Mailguard és amavisd-new 
párost, ahol több mint 350.000 e-levelet kezelnek naponta, 
tehát a megoldás skálázható, amennyiben elegendően jó 
alkatrészek állnak rendelkezésünkre. 
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Mint azt valószínűleg sokan megfigyelték, a spam és víru- 
sok elleni harcban éppen a nyílt forrású eszközök a legjobb 
fegyverek. Az amavisd-new, Maia Mailguard, Spam- 
Assassin és a Clam Antivirus segítségével hálózatunknak 
elsőrangú védelmet adhatunk anélkül, hogy hatalmas költ- 
ségekbe vernénk magunkat. 


Linux Journal 2004. december, 128. szám 


Robert LeBlanc a Renaissoft elnöke 
(www.renaissoft.com), a Mala Mailguard szer- 
zője, és az AnswerSguad spam-harcos guruja 
(wwvw.answersguad.com). Amikor éppen nem 
a spanyolviaszt találja fel vagy még jobb egér- 
csapdákat fabrikál, általában négy Alaszkalja 
Klee Kai, Zorro, Sikari, Plyomi és persze a Mala 
társaságában található. 





2 www.ijs.si/software/amavisd 
2 www.renaissoft.com/mala 

2 wwvw.spamassassin.org 

2 www.clamav.net 

9 razor.sourceforge.net 

9 pyzor.sourceforge.net 
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Cikkgyújtemények tartalmának begyújtése 


Adjunk lehetőséget alkalmazásunknak, hogy kedvenc weblapjainkról összegyűjtse 


a friss írásokat! 


z elmúlt néhány hónapban az RSS és Atom 
AA XML-alapú fájlformátumokkal foglalkoztunk, 

azzal a párossal, mellyel könnyedén elkészíthet- 
jük és elterjeszthetjük egy weboldal összefoglalóját. 
Igaz ugyan, hogy -— mint az ismeretes - az ilyesfajta 
cikkgyűjtemények készítése hagyományosan inkább 
a Weblogokra és híroldalakra jellemző, egyre nagyobb az 
érdeklődés más területeken is. Bármilyen web alapú in- 
formációforrás esetében érdekes és hasznos jelölt lehet 
akár az RSS akár az Atom. 
Ez idáig azt néztük meg, hogyan készíthetünk RSS és 
Atom tartalmat Weblapunkhoz. lermészetesen az cikk- 
gyűjtemény tartalom elkészítése csak az egyenlet fele. 
Legalább ilyen fontos és talán még hasznosabb megérteni, 
hogyan szerezhetjük be és használhatjuk ezeket az cikk- 
gyűjtemény tartalmakat saját webhelyünkről és más érde- 
kes oldalakról. 
Amint azt láthattuk, három különböző cikkgyűjtemény 
tartalom létezik: az RSS 0.9x és fejlettebb verziója az RSS 
2.0, a nem együttműködő RSS 1.0, valamint az Atom. Vala- 
mennyi nagyjából azonos feladatot végez el és elég nagy 
mértékű átfedés van a szabványok között. Ugyanakkor, 
a hálózati protokollok általában nem működnek valami 
fényesen, ha naivan feltételezzük, hogy minden rendben 
lesz és elegendően azonos működésű. Ez alól az cikkgyűj- 
temények sem kivételek. Amennyiben valamennyi össze- 
sítővel rendelkező lapot el szeretnénk tudni olvasni, az 
összes protokollt és azok verzióit is meg kell értenünk. 
Az RSS például jelenleg kilenc különféle verzióval rendel- 
kezik amelyhez ha az Atom-ot is hozzávesszük, összesen 
tíz különféle cikkgyűjtemény formát használhat valamely 
weblap. A legtöbb eltérés valószínűleg elhanyagolható, 
de nem lenne bölcs dolog teljesen figyelmen hagyni őket, 
vagy feltételezni, hogy mindenki a legfrissebb verziót 
használja. Ideális esetben van valamilyen modulunk vagy 
eszközünk amely több különféle protokoll nyelvén is ért 
eltüntetve a különbségeket, miközben valamennyi proto- 
koll egyedi előnyeit kihasználja. 
E hónapban Mark Pilgrim univerzális tartalom értelmező- 
jét (Universal Feed Parser) vesszük szemügyre, amely e 
problémára kínál nyílt forráskódú megoldást. Pilgrim jól 
ismert weblog szerző és Python programozó, valamint az 
Atom cikkgyűjtemény formátum megalkotásának egyik 
kulcsfigurája. Ez persze nem is meglepő, ha azt vesszük 
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mennyi problémába ütközött az Universal Feed Parser 
megíráskor. A program a Microsoft üzleti CDF formátu- 
mát is kezeli, amely az aktív asztal és programfrissítések 
összesítőit terjeszti. A Linux asztali felhasználók számára 
ez a rész talán nem túl izgalmas viszont érdekes egysége- 
sítési lehetőséget kínál a már telepített Microsoft rendsze- 
rekkel. Az Universal Feed Parser jelenleg a 3.3 verziónál 


a a 


licensztől függetlenül. 


A feedparser telepítése 

A feedparser telepítése rendkívül egyszerű. Töltsük le 

a legfrissebb verziót, tegyük a telepítési könyvtárába és 
gépeljük be a 


python setup.py installc 


parancsot. Ezzel elindítjuk a Python szabványos telepítési 
eszközét, amely a feedparser-t a Python site-packages 
könyvtárába helyezi. A feedparser telepítése után próbáljuk 
ki a Python segítségével valamelyik héjablakból: 


sss import feedparser 


A 555 jelek az interaktív módban meghívott Python 
szabványos parancssorának felelnek meg. A fenti utasí- 
tás beolvassa a feedparser modult a Pythonba. Ha nem 
telepítettük a feedparser-t, vagy valamilyen gond tör- 
tént telepítés során, a parancs végrehajtása Python 
ImportError hibát okoz. 

Miután importáltuk a modult a memóriába, nézzünk 
belea legfrissebb hírekbe a Linux Journal weblapján. 
Gépeljük be: 


sss Ijfeed - feedparser.parse 
(http: //ww. linuxjournal . com/news . rss") 


Nem szükséges megadnunk milyen protokoll vagy verzió 
szerinti tartalmat szeretnénk az értelmezővel feldolgoztatni 
— a csomag elég okos ahhoz, hogy magától felismerje a ver- 
ziókat, még olyankor is amikor az RSS tartalom maga nem 
tudja beazonosítani a verzióját. Írásunk születésekor a LJ 
lapja PHPNuke alapú az tartalmat használ, melyet egyértel- 
műen RSS 0.91 típusként sikerült azonosítani. 
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Miután letöltöttük az új tartalmat, megnézhetjük pontosan 
hány bejegyzést kaptunk, amit többé kevésbé a kiszolgáló 
beállításai határoznak meg: 


sss lenCiIjfeed.entries) 


természetesen, az elemek száma kevésbé érdekes mint 
az elemek maguk, ezeket egy egyszerű for ciklussal 
kaphatjuk meg: 


sss for entry in Ijfeed.entries: 
print entry[/title ] 


Ne feledjük, a ciklus sorait beljebb kell kezdenünk, 
hogy a Python tudja mely sorok tartoznak a ciklusba. 
Aki még csak most ismerkedik a Python nyelvvel, esetleg 
furcsának találja a . . . jelzéssel kezdődő sorokat ame- 
lyek azt mutatják, hogy a Python készen áll és a for cik- 
lus utáni sorokra várakozik. A ciklus végrehajtásához 
egyszerűen csak nyomjunk ENTER-t és máris láthatjuk az 
összes fÍriss címet. 

Csinos átnézeti képet kaphatunk az URL-ekről és 

a címekről a Python karaktersorozat behelyettesítésének 
segítségével: 


sss for entry in Ijfeed.entries: 
print "ca href-"9s"59s5c/az" JN 
C(entry[ link], entry[l/ title ]) 


Mint korábban jeleztem, a feedparser megpróbálja felolda- 
ni a különböző verziók közötti különbségeket, és úgy dol- 
gozhatunk a különböző összesítési formákkal mintha azok 
nagyjából azonos módon működnének. Ezért a fenti paran- 
csokat saját weblogom cikkgyűjtemény tartalmára is megis- 
mételhetem. Nemrég tértem át a WordPress-re, amely Atom 
tartalmat használ: 


sss altneufeed - feedparser.parse( 
"http://altneuland. lerner. co. 11/wp-atom.php") 
sss for entry in altneufeed.entries: 
print "ca href-"9s"599s5c/az" JN 
(entry.link, entry.title) 


Figyeljük, meg hogy ez az utóbbi példa az entry. link és 
entry. title attribútumokat használja, míg a korábbi pél- 
dánk az entry[" link" ] és entry[/title" ] könyvtárhivat- 
kozásokat alkalmazta. A feedparser rugalmasan próbálja 
megközelíteni a problémát, és egyazon információhoz 
többféle elérési lehetőséget kínál, kiszolgálva a különböző 
igényeket és stílusokat. 


Milyen friss a hír? 

A hírösszesítők és más RSS vagy Atom használó alkalmazások 
fő célja a nemrégiben frissített hírek összegyűjtése és bemuta- 
tása. Az hírösszesítő csak azokat a híreket szolgáltathatja ame- 
lyeket a kiszolgáló felajánl. Amennyiben az RSS tartalom csak 
a két legutóbb frissített elemet tartalmazza, az hírösszesítő fe- 

lelőssége begyűjteni, gyorstárazni, és megjeleníteni azokat az 

elemeket, amelyek már nem kerülnek az összesítőkbe. 
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Ez két eltérő, bár szoros kapcsolatban álló kérdést vet fel: 
Hogyan biztosíthatjuk, hogy az összesítő csak olyan 
elemeket mutasson, amelyeket még nem láttunk? Van-e 
lehetőség rá, hogy az hírösszesítőnk csökkentse a terhe- 
lést a weblog kiszolgálón, és csak azokat a bejegyzéseket 
töltse le amelyek a legutóbbi frissítésünk óta kerültek fel? 
Az első kérdésre a válasz, hogy minden egyese elemnél 
ellenőriznünk kell a módosítási dátumot, amennyiben 

az létezik. 

A második kérdés jelenleg egyre népszerűbb vitatéma 

a webes közösség berkeiben. Ahogy a weblog népszerű- 
sége növekszik, úgy nő az egyes cikkgyűjteményekre 
feliratkozó emberek száma is. Ha a weblog cikkgyűjte- 
mény tartalma 500 feliratkozót szolgál ki, és az összes fel- 
iratkozott óránként gyűjti be a frissítéseket, az óránként 
további 500 lekérdezést jelent amit a Webkiszolgálónak 
teljesíteni kell. Ha a cikkgyűjtemény tartalom a teljes 
webhelyet lefedi ez igen komoly elpazarolt sávszélessé- 
get is jelenthet — ami csökkenti az oldal válaszidejét más 
látogatók számára, illetve előfordulhat, hogy az oldal 
tulajdonosának fizetnie kell a engedélyezett havi sávszé- 
lesség túllépése miatt. 

A feedparser használatával önmagunkhoz és az összefoglaló 
kiszolgálóhoz is kíméletesek lehetünk, ugyanis lehetővé te- 
szi, hogy csak a akkor töltsük le az cikkgyűjtemény tartal- 
makat, ha van figyelemre méltó újdonság. Ez úgy lehetsé- 
ges, hogy a HITP modern verziói lehetővé teszik, hogy 

a kérelmező ügyfél beállítsa az If-Modified-Since (adott idő- 
pont óta módosult) fejlécet, amit a dátum követ. Amennyi- 
ben a kért URL módosult a megadott dátum óta, a kiszolgá- 
ló az URL tartalmával válaszol. Ha viszont a kért URL vál- 
tozatlan, a kiszolgáló a 304-es válaszkódot küldi, jelezve, 
hogy az aktuális tartalom továbbra is a korábban letöl- 

tött verzió. 

Mindezt úgy érhetjük el hogy egy lehagyható módosító 
paramétert adunk át a feedparser.parse() függvénynek. 
Ez a paraméter a time modul szerint megadott szabványos 
Python szerkezet, melyben az első hat elem az év, hónap 
szám, nap szám, óra, perc és a másodperc. Az utolsó három 
elem minket jelenleg nem érdekel így nyugodtan hagyhat- 
juk őket 0 értéken. lehát, amennyiben a 2004 Szeptember 1. 
óta beérkezett tartalmakat akarjuk látni, a következőket 
gépeljük be: 
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last retrieval — (2004, 9, 1, 0, 0, 0, 0, 0, 0) 
ljfeed - feedparser.parse( 
"http: //ww. linuxjournal . com/news . rss") 


Ha a Linux Journal kiszolgálója helyesen van beállítva 

a fenti kód a teljes cikkgyűjtemény tartalmat letölti az 
Ijfeed-be és vagy a HTTP Ok állapot üzenetet kapja vissza 
(melynek számszerű kódja 200) vagy egy jelzést, misze- 
rint a az adat nem változott az utolsó letöltés óta (amely- 
nek számszerű kódja 304). Igaz ugyan, hogy ha tárolni 
szeretnénk mikor kértük le az utolsó cikkgyűjtemény 

tar talmat, több bejegyzést kell nyilvántartanunk, mégis 
fontos betartanunk ezt a szabályt, különösen ha rendsze- 
resen kérünk tartalom frissítéseket, ugyanis ellenkező 
esetben alkalmazásunk nem igazán lesz szívesen látott 
vendég bizonyos honlapokon. 
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Szaktekintély 
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T. lista aggregator.py 


1! /usr/bin/python 


import feedparser 
import sys 


ff a személyes tartalom kimeneti állomány 
f megnyitása 


aggregation filename - "myfeeds.html" 
max title chars - 60 


Ery- 
aggregation file 
open Caggregation filename, "w") 
aggregation file.write(C("""-c-html:5 
cheadsctitleszMy newsc/titlesc/heads 


cbodyz""") 

except IOError: 
print "Error: cannot write "9857" 96N 
aggregation fi lename 
exit 

H EE S Nee Tea EE Me e e e ee e E et 


$ A feeds.txt minden nem üres sora 
$ tartalom forrás. 


feeds filename - "feeds.txt" 
feeds list — [] 


Erys 
feeds file - open(feeds filename, r ) 
for line in feeds file: 
stripped line - line.stripO .rstripO 


if lenCstripped line) 5 0: 
feeds list.append(stripped line) 
sys.stderr.write("Adding feed 774N 
stripped line £ "4 —n7) 


feeds file.closeO 


except IOError: 
print "Error: cannot read $s " 9 


Munka a tartalmakkal 

Most már van némi elképzelésünk róla, hogyan kell dol- 
gozni a feedparser-el, készítsünk hát egy egyszerű összesí- 
tő eszközt. Eszközünk bemenetét a feeds.txt állományból 
kapja kimenetét pedig a feeds.htmi HTML állományban 
adhatjuk meg. A programot a cron eszközzel futtatva 

és naponta belenézve a HTML állományba egyszerű de 
működőképes hírtartalmat kaphatunk a minket leginkább 
érdeklő honlapokról. 

A feeds.txt állomány a tényleges tartalmak URL-jeit tartal- 
mazz és nem a honlapok címét ahonnét az abrakot le sze- 
retnénk tölteni. Más szóval a felhasználóra bízzuk, hogy 
megtalálja és bevigye minden egyes tartalom URL címét. 
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3 -feeds fi1lename 
exit 


f végiglépdelünk a feeds list listán, 
f és leszedjük a megfelelő tartalmat 


for feed ur] in feeds list: 
sys.stderr.write("checking "96s  .. 
feed ur1]) 
feed - feedparser.parse(feed url) 
sys .stderr.write("done.N n7) 


sk Es70 


aggregation file.write( ch259s5ca/h2sV né JN 
feed.entries[0].title) 


ft végiglépdelünk az tartalom összes 

f bejegyzésén, megjelenítjük és beírjuk 

f az összefoglalóba 

for entry in feed.entries: 
sys.stderr.writeC("v tWwrote: "985 7 96 

entry.title[l0:max title chars]) 


if lenCentry.title) 5 max title chars: 
sys.stderr.writeC("...") 


sys.stderr.writeC("w n") 


aggregation file.write( 
" al13ca href—-9s"5s98sc/axv ni 9 
(entry.link, entry.title)) 


aggregation file.write( ca/u2s5vn ) 


f HTML befejezése 


aggregation file.writeC("""-/bodyz 
c/htmls 
cc ús 20) 


aggregation file.closeO 


A kifinomultabb összesítő eszközök általában képesek be- 

azonosítani a tartalom URL címét a a webhely honlapjának 

fejlécében található link tag alapján. 

Ráadásul, a korábbi figyelmeztetésem ellenére, miszerint 

minden hírösszesítőnek követnie kellene a legfrissebb híre- 

ket hogy ne terhelje túl a kiszolgálókat, ez a program nem 

tartalmaz ilyen képességet, hiszen megpróbáltam a tömör- 

ségre és olvashatóságra törekedni. 

Az 1. listában olvasható aggregator.py nevű program négy 

részre bontható: 

1. Először is megnyitjuk a kimeneti fájlt, azaz a myfeeds.htmIl 
nevű HIML formátumú szöveges állományt. Ezt a z állo- 
mányt Webböngészőben való nézegetésre szánjuk. 


Ezt a helyi, fi le:/// URL-el megadott állományt akár fel 
is vehetjük a személyes könyvjelzőink közé, vagy esetleg 
beállíthatjuk kezdőlapnak is. Miután meggyőződtünk ró- 
la, hogy valóban tudunk írni az állományba, megkezdjük 
a HIML állományt. 

2. Beolvassuk a feeds.txt tartalmát, amelyben soron- 
ként egy tartalom URL található. Hogy elkerüljük 
a szóközök és üres karakterek használatából adódó 
problémákat, levágjuk az üres karaktereket és figyel- 
men kívül hagyunk minden sort amiben nincs legalább 
egy nyomtatható karakter. 

3. Ezek után végiglépkedünk a feeds list tartalom 
listán, és meghívjuk feedparser.parseO) függvényt az 
adott URL-re. Ha kapunk választ, kiírjuk a myfeeds.html 
kimeneti állományba, az URL-el és a cikk címével 
együtt. 

4. Végül lezárjuk a HIML-t és az állományt. 


A kódba belepillantva láthatjuk, hogy személyes használat- 
ra nagyon könnyen készíthetünk hírösszesítőt. Persze ez 
csak nagyon vázlatos alkalmazás. Ha használhatóbbá sze- 
retnénk tenni, valószínűleg érdemes lenne a feeds.txt és 
myfeeds.html tartalmát relációs adatbázis-kezelőbe vinni, 

a tartalom URL címét pedig automatikusan vagy félauto- 
matikusan meghatározni a lap URL címe alapján, továbbá 
érdemes lenne tartalom kategóriákat is alkalmazni, így 

a többszörös tartalmak egységes egészként lennének olvas- 
hatóak. Amennyiben a leírás ismerősen hangzik, a kedves 
olvasó biztosan Bloglines felhasználó, hiszen ez a web- 


alapú blog gyűjtögető éppen a fenti módon működik. Nyil- 
vánvaló módon a Bloglines sokkal több tartalmat és sokkal 
több felhasználót kezel mint amennyi az egyszerű játékpél- 
dánkban található. Ha el szeretnénk készíteni a Bloglines 
belső szervezeti verzióját, némi személyre szabott kóddal 
kiegészített Universal Feed Parser és egy adatbázis-kezelő 
(például a PostgreSOL) alkalmazásával a kialakítás egyaránt 
könnyű és hasznos is. 


Osszefoglalás 

A spanyolviasz feltalálásának esetét gyakran említik a számí- 
tógépipar problémájaként. Mark Pilgrim Universal Feed 
Parser programja lehet, hogy csak egy apró igényt elégít ki 

a programok világában, de ez az igény szinte bizonyosan nö- 
vekedni fog, ahogy az cikkgyűjteményeket használó szemé- 
lyek és szervezetek száma egyre szaporodik. Amennyiben 
kedvünk támad cikkgyűjtemény tartalmakat olvasni vagy 
értelmezni, érdemes használnunk a feedparser-t. Kipróbált és 
jól dokumentált alkalmazásról van szó, amely gyakran frissül 
és fejlődik, munkáját pedig gyorsan és jól végzi. 
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A felhasználói viselkedés vizsgálata (4. rész) 


A sorozat előző részében megvizsgáltuk, hogyan juthatunk a modellezéshez 
szükséges adatokhoz. Most egy egyszerű program segítségével bemutatom 
az alkalmazott algoritmusokat és azok különböző paraméterezési lehetőségeit. 


z eddigiekben körüljártuk az elméleti lehető- 
AA ségeket: modellezési kérdések és modelltípu- 

sok, adatgyűjtési módszerek, felhasználók 
azonosítása és elkülönítése. Most nézzük meg, hogy 
hogyan lehet használható modelleket, adatokat készíte- 
ni. Ehhez egy PHP nyelven írt szkriptet használunk, illet- 
ve ezen keresztül vizsgáljuk meg a lehetőségeket és az 
eredményeket. 


Követelmények 

Néhány elérhető modellező szoftver vizsgálata után 
fogalmaztam meg a legfontosabb követelményt: minél 
többféle modell készítését támogassa az eszköz, az előállí- 
tott adatsorokat lehessen később más szoftverrel is feldol- 
gozni (grafikus megjelenítés, elemzés), azaz legyen felké- 
szítve sokféle (elsősorban szöveges) formátumú kimenet 
előállítására. 


Előszűrés 

A megvalósítandó eszköz egyik legfontosabb része az 
előfeldolgozó. Az általános felhasználhatósághoz ennek 

az alrendszernek széles paraméterezhetőséggel kell rendel- 
keznie, hogy bármilyen portál rendszer eseménynaplóját 
fel tudja dolgozni. 


Három elkülöníthető funkcióra van szükség: 

e . Kihagyás. A modellezés során a portáltól függően renge- 
teg eseménynapló bejegyzés nem hordoz releváns 
(a modellezés szempontjából felhasználható) informáci- 
ót. Ezeket a bejegyzéseket ki kell venni, mert csak zavar- 


nák és lassítanák a feldolgozás és modellalkotás menetét. 


e . Összevonás. A webszerverek és a HTTP protokoll lehe- 
tőséget nyújt ún. átirányításokra. Ez azt jelenti, hogy ha 
a felhasználó adatokat küld a szervernek, az azt feldol- 
gozó program a lefutása után gyakorlatilag észrevétle- 
nül egy másik weboldalra küldi tovább a kliens böngé- 
szőjét. Másik lehetőség, hogy egy weboldal több keret- 
ből (frame) áll, ekkor az egyes keretekbe betöltődő 
weblapok mind külön-külön bejegyzéseket jelentenek 
az eseménynaplóban. Ilyen esetekben tehát szükség le- 
het több eseménynapló bejegyzés összevonására, és egy 
weboldalként való szerepeltetésére a modellezés során. 
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e Átalakítás. Egy másik jellemző megfontolás, hogy 
a portál összes weboldala egy fájlon keresztül érhető el. 
Ekkor az eseménynaplóban is csak ez az egy fájl jelenik 
meg, de a HIIP kérésből kiolvashatóak a paraméterek. 
Ebben az esetben arra van tehát szükség, hogy az ilyen 
paraméterezett lekérésekből egyszerű, könnyen olvas- 
ható és a lényeget kiemelő , weboldalakat" (tartalmat jel- 
lemző, címet és nevet tükröző modell bejegyezéseket) 
csináljunk. 


Az előszűrés feladata továbbá, hogy a feldolgozhatatlan 
eseménynapló bejegyzéseket is eltávolítsa. Ilyen bejegy- 
zések például a hibák, a nem létező erőforrásokra mutató 
lekérések. 


Felhasználói azonosítás 

A megvizsgált szoftverek között van, amelyik képes az 
egyes eseménynapló bejegyzéseket elkülöníteni, és egy- 
egy látogatóhoz rendelni. Ezen szoftverek legnagyobb 
hátránya az volt, hogy sehol nem volt elérhető a használt 
módszerfek) leírása. (Az általam használt módszerekről 
cikksorozatom előző részében volt szó). Ezen okból kifo- 
lyólag a legfontosabb követelmény az, hogy az eszköz 
képes legyen a lehető legtöbb módon ezt a hozzárende- 
lést elvégezni, és az egyes módszerek paraméterei széles 
skálán legyenek állíthatók (ne legyenek ,bedrótozva" 

a szoftverbe). 

A felhasználók elkülönítésére használatos módszereket 
alapvetően meghatározza a rendelkezésre álló esemény- 
napló, ezért szükséges, hogy a szoftver ilyen képességét 
(felhasznált metódusokat) mindig az adott adatforráshoz 
lehessen igazítani. 


A lehetséges módszerek: 

e . munkamenet azonosító alapján, amelyet a webszerver 
helyez el az eseménynaplóban; 

e idő (két lekérés között eltelt idő figyelése) és kliens IP 
cím alapú hozzárendelés legegyszerűbb (legkevesebb 
adatot tartalmazó) eseménynaplók esetén; 

e részletesebb eseménynaplók esetén a referer és user 
agent értékek is bevonásra kerülnek az összerendelés 
folyamatának pontosításába. 


Az eseménynapló két bejegyzése akkor tartozik egy felhasz- 
nálóhoz, ha a weboldal lekérések között eltelt idő értéke 
(idő paraméter) kisebb, és akkor különítendő el más-más 
látogatóhoz, ha nagyobb, mint a beállított idő paraméter 
értéke. Ezen idő paraméter értéke nagymértékben befolyá- 
solja a létrejövő modelleket (látogatók száma, különböző 
útvonalak megoszlása, stb.), ezért kiemelten kell kezelni 
ennek beállítási lehetőségét. 


Exportálás 

A szoftverrel szemben nem követelmény, hogy szép formá- 
ban (grafikusan, szemléletesen) állítsa elő az eredményt, 

de fontos cél, hogy az adatokat többféle szöveg alapú for- 
rásba képes legyen menteni a további feldolgozhatóság mi- 
att. A lehetséges formátumok például: text, CSV (comma 
separated value), XML, HTML. Ez azért szükséges, hogy 
további modellező és megjelenítő eszközök felé biztosított 
legyen az átjárás, megkönnyítve ezzel az érthetőséget és 

az ellenőrzést. 


Az analizáló szoftver 

Az analizáló szoftver egymás utáni feldolgozási lépések fo- 
lyamatából áll, ugyanakkor a további felhasználás és fejlesz- 
tés szempontjából érdemes egy osztályba összefogni az 
egyes lépéseket megvalósító kódokat. Ennek további elő- 
nye, hogy az OOP-szemlélet következtében az esemény- 
napló vizsgálatának eredménye egyszerűen beilleszthető 
egy másik szoftverbe is (például egy általános eseménynap- 
ló statisztikai programba). 


A fentieknek megfelelően a szoftver két fájlból áll: 

e . A WebuserModeller.class.php tartalmazza azt az osz- 
tályt, amely egybefogja a modellezés lépéseit megvaló- 
sító függvényeket, a függvények által közösen használt 
változókat, elrejti a belső funkciókat (például: esemény- 
napló sor beolvasása) és megfelelő metódusokat (inter- 
fészeket) biztosít az igénybevételhez. A modellezést 
végző kódok és algoritmusok ebben az osztályban talál- 
hatóak meg. 

e A wum.php használja az előzőekben ismertetett osztályt 
a vizsgálathoz. Egyes paramétereket a wum.php prog- 
ramkódjában lehet változtatni, ezeket a beállításokat 
ebben a fájlban lehet megadni (például: vágási küszöb- 
értékek). Ez a fájl biztosítja jelenleg a modellező osztály 
használatának lehetőségét. 


Az elemzőprogram a wum.php parancssori meghívásával 
indítható el a megfelelő paraméterek megadásával. Feladata 
a megadott paraméterek szerint (használt konfigurációs fájl, 
elkészítendő modell típusok, kimeneti könyvtár) a modelle- 
ző osztály megfelelő metódusaink meghívása, és a létrejött 
eredmények feldolgozása, ami jelen esetben a fájlba men- 
tést jelenti. 


Konfigurációs lehetőségek 

Minden eseménynaplóhoz készíteni kell egy konfiguráci- 
ós fájlt, amely az adott naplófájlra jellemzően és a felhasz- 
nálás módjától függően tartalmazza a modellezési paramé- 
tereket. Ezek a paraméterek alapvetően befolyásolják az 
elkészülő modelleket. 
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A következő paramétereket kell beállítani a konfigurá- 
ciós fájlban: 


log file: az analizálandó eseménynapló elérési útvonala, 
kötelezően megadandó. 

base href: a portál alap linkje (URI). 

use cookie: a felhasználók azonosításához lehetőség van 
munkamenet azonosító használatára. Ellenkező esetben 
idő alapú elkülönítéssel választja el a szoftver a látoga- 
tókat. Alapértelmezésben nem munkamenet alapú azo- 
nosítás történik. 

root page: a weben általában egy portál nyitóoldalának 
eléréséhez elegendő egy tartomány címet (például: 
http:[/www.linuxvilag.hu) ismerni, nem kell a pontos 
kezdő fájl teljes nevét is manuális megadni (például: 
http:/[/www.linuxvilag.hulfindex.html), ugyanakkor a hát- 
térben mindig van egy fájl. A két elérési lehetőség egy- 
beolvasztásához lehet itt megadni a kezdő fájl nevét, és 
a szoftver automatikusan lecseréli a nyitóoldali lekérése- 
ket az itt megadottra, így biztosítva a modellek egysé- 
gességét. Elhagyása esetén nem kerül figyelembevételre. 
allow without extension: hasonló a root page-hez, beál- 
lításával a modellezés során a könyvtár lekéréseket lehet 
kihagyni illetve bevonni az analizálásba. Alapértelme- 
zésben megengedő állapotú. 

remove get params from reguest: a kérésekben szereplő 
GET paramétereket lehet eltávolítani, így például a fel- 
használó adatküldéseit lehet kiszűrni, vagy a GET para- 
méterbe kódolt különböző oldalakat lehet egynek ven- 
ni, ezáltal akár radikálisan csökkentve a modellek fel- 
bontását. Alaphelyzetben nem engedélyezett. 

time window: a legfontosabb paraméter, ezt az időt 
veszi alapul a szoftver a felhasználók elkülönítésénél. 
Ha a use cookie be van kapcsolva, akkor ezen érték 
nem kerül felhasználásra. Megadása kötelező. 

reguest file types: az analízis folyamat az itt megadott 
típusú fájlokat (lekéréseket) veszi csak figyelembe a mo- 
dellalkotás során. Ha nem szükséges a képek lekérései- 
nek modellezése, akkor itt nem kell megadni az adott 
portálra jellemző képtípusokat. Azokat a fájltípusra jel- 
lemző karakterláncokat kell megadni felsorolva, ame- 
lyek szerepelhetnek az engedélyezett kérésekben. 

A szoftver egyszerű mintakeresést végez. Mivel ez 

a modellezés egyik alapbeállítása, ezért mindenképpen 
meg kell adni a feldolgozandó kérések jellegét. 

reguest simplify: a modellezést nem befolyásolja köz- 
vetlenül, azonban megkönnyíti a modell elemzését azál- 
tal, hogy a megadott paramétereknek megfelelően az 
egyes lekéréseket egyszerűbb szövegre cseréli le (példá- 
ul: index.php?"modul-boltgkategoria—muszaki cikk he- 
lyett csak ennyi lesz a kimeneti eredményekben: bolt- 
muszaki cikk). A cserélendő kérésre jellemző (vagy az- 
zal megegyező) mintához kell megadni az új (cserélt) 
karaktersorozatot. Opcionális paraméter. 

groupize path: az előszűrésnél említett összevonásokat 
lehet itt megadni Az új, összevont kéréshez fel kell so- 
rolni az összevonandó kérésekre jellemző mintákat. 
Opcionális. 

page referers: az analízis során a felhasználók elkülöni- 
téséhez felhasználható a combined szerkezetű esemény- 
naplókban szereplő referer érték is. Itt lehet megadni, 
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hogy az egyes weboldalakhoz mely másik weboldalak 
tartozhatnak refererként. A portál weboldalaihoz felsoro- 
lásszerűen kell megadni a lehetséges referer értékek 
mintáit. Ha egy adott weboldalhoz nincs megadva le- 
hetséges referer érték, az azt jelenti, hogy bármilyen 
referer értéket elfogadunk. Opcionális, csak a megadott 
weboldalaknál használja, vagyis minden egyes web- 
oldalra külön-külön lehet megadni. 


Használat, indítási paraméterek 

Az analizáló szoftver képességei a wum.php indításával 
használhatók ki. Kötelezően megadandó paraméter 

a --ini, amely értéke határozza meg a felhasználandó 
konfigurációs fájl útvonalát. 


A következő paraméterek opcionálisak: 


e — --help: minimális leírást ad a megadandó paramé- 
terekről. 
e  --output: a kimeneti fájlok mentési könyvtára, ha nincs 


megadva, akkor a wum.php futtatási könyvtárába ke- 
rülnek az eredményeket tartalmazó fájlok. 

e  --version: a különböző beállításokkal készült modelle- 
zések elkülönítéséhez lehetőség van egy verziószám 
megadására, ez a verzió azonosító az eredmény fájlok 
nevét befolyásolja (hozzáfűzésre kerül), elhagyása ese- 
tén egy időbélyeggel helyettesítődik. Létező fájlnév 
esetén automatikus felülírás történik. 

e  --diff: az a küszöbérték, amely alatti előfordulásokat 
az egyes eredményekből el kell távolítani. A viszonyítás 
alapja a felhasználói útvonalak száma (vagyis az összes 
látogató száma). Megadása opcionális, alapértéke a 0, 
ekkor nem kerül figyelembe vételre. 

e  --model: a különböző lehetséges modellek elkészítését 
lehet bekapcsolni segítségével. Elhagyása esetén min- 
den lehetséges modellezési folyamat lefuttatásra kerül. 

e A --model paraméter lehetséges értékei és a hozzá tar- 
tozó modellek: 

e up (user path): A modellezés alapja, a felhasználók elkü- 
lönítését és az útvonalak összegyűjtését végzi. A további 
modelltípusok elkészítéséhez ennek a modellnek már 
rendelkezésre kell állnia. 

e ro (routes): a felhasználók útvonalait állítja össze, meg- 
számolja, hogy ugyanazokat a weboldalakat hány kü- 
lönböző látogató járta végig. Itt a weboldalak megláto- 
gatási sorrendje is számít. 

e sp (same pages): abban különbözik a routes adatoktól, 
hogy itt már nem számít az oldalak sorrendje, tehát 
csak azt vizsgáljuk, hogy a felhasználók közül egy lá- 
togatás során hányan jártak azonos oldalakon (a teljes 
látogatást tekintve). 

e  ct (click times): az egyes weboldalak közötti átkattintási 
időminimumokat, időmaximumokat és időátlagokat 
mutatja. lovábbi felhasználása: az itt kapott értékek 
alapján munkamenet azonosító nélküli, idő alapú ese- 
ménynapló elemzés. 

e wmi(web model in): azt mutatja meg, hogy az egyes 
oldalakra honnan és hányszor érkeztek a felhasználók. 
A bejövő (tulajdonképpen az előző) oldalakra nincs szű- 
rés, így nincsenek elkülönítve a kívülről illetve a portá- 
lon belülről érkezettek. 
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different reguestű 


Van még bejegyzés? 





1. ábra Munkamenet azonosító alapú analízis 


e. wmo (web model out): hasonló a wmi modellhez, a kü- 
lönbség az irányban van. Ebben az esetben azt vizsgál- 
juk, hogy egy adott weboldalról melyik másik web- 
oldalra léptek tovább a felhasználók. 

e dr (different reguests): az eseménynaplóban megtalálha- 
tó összes különböző kérést gyűjti ki. Nem igazi modell, 
segédeszköz a modellezés paramétereinek pontosításá- 
hoz. Önmagában is használható. 


Működés, algoritmusok 

Az analizáló szoftver lineáris lefutású: eseménynapló sorá- 
nak beolvasása, feldolgozás, az adatok szerint egy felhasz- 
náló keresése vagy új létrehozása, majd a különböző mo- 
dellek összeállítása a felhasználók adatsorai alapján. 

Az analizáló szoftver legfontosabb része a felhasználók 
elkülönítéséért felelős rész, mert minden további modelle- 
zést végző részfeladat ennek az eredményein operál. 


Felhasználók válogatása 

e . Felhasználók válogatása munkamenet azonosítók alap- 
ján: A munkamenet azonosító alapú eseménynapló ana- 
lízis folyamata egyszerű, mert minden egyes bejegyzés- 
ben már szerepel a látogatókat egyértelműen elkülönítő 
(azonosító) adat. Ez a módszer egyszerűen az azonosító 
alapján tömbbe gyűjti a látogatókat (1. ábra), és a hozzá- 
juk tartozó weboldal lekérések paramétereit. A szoftver 
ebben az esetben nem veszi figyelembe az IP címet, 
időbélyeget, referert, stb., hiszen ezeket az adatokat 
a webszerver a weboldal lekérésekor , belekódolta" 
a munkamenet azonosítóba. 

e Felhasználók válogatása idő alapú elkülönítéssel: 
A látogatók elkülönítése és útvonalaik összegyűjtése 
elsődlegesen az IP cím, távoli eseménynapló, távoli 
felhasználó adatok alapján történik. Ez önmagában 
nem elegendő az egyértelmű megkülönböztetéshez. 
További segítséget nyújt a referer és a böngésző adatok 
jelenléte. Azonban a legegyszerűbb szerkezetű ese- 
ménynaplók nem tartalmaznak az IP címen és a kérés 
időpontján kívül több olyan adatot, amely segítené 
a látogatók elkülönítését, vagy egy nagyvállalati háló- 
zatból érkező látogatók esetén jellemzően a böngésző 
adatok is azonosak. 


Az idő alapú elkülönítés során (2. ábra) az éppen vizsgált 
kérést a megadott időintervallumon belül eső, kéréssel ren- 
delkező látogatóhoz próbáljuk meg csatolni, oly módon, 
hogy a fent említett adatok közül a lehető legtöbb egyez- 
zen. leljes egyezés esetén a vizsgált kérést az adott látoga- 
tóhoz kapcsoljuk, ha nem találtunk teljes egyezést, akkor 
mint új látogató kezeljük, és egy új útvonal tömb bejegy- 
zést nyitunk neki. 





Kérés 
elfogadható? 


Van útvonal? 


-analyze by time0 


2. ábra Idő alapú analízis 


Létezik útvonal tömb? 


vSRLGERt 


routea 


Van még felhasználó? 


Nem 


Igen 
Küszöbérték? 
Nem 


3. ábra Különböző útvonalak modellezése 


Felhasználói útvonalak 

Az analízis eredményeképpen előálló felhasználónkénti le- 
kéréseket (útvonalakat) mutatja meg. Az eredmény egy 
többdimenziós tömb, amely felhasználónként tartalmazza 
az egyes (sorrendben) lekért weboldalakat és néhány, az 
egyes kérésekhez tartozó kiegészítő adatot. Ez egy inter- 
fész, a tömb valójában az analizáló alrendszer eredménye. 


Például: 


[15] —5 Array 
( 
[0] —5 Array 
( 
[ipnaddress] 
[remote log] 
luser id] 
[time] —- 


-s 213.157.96.206 

—s  — 

5 - 

1050899398 

[reguest] -—5 /index.php 

[referer] —5 http://ww. jegyzet. com/ 
[user-agent] -5 Mozilla/4.0 (compatible; 
S5MSIE 6.0; Win98) 


[1] —5 Array 
( 
[ipnaddress] 
[remote log] 
[user id] — - 
[timel -5 1050899431 


ss 213.157.96.206 
s-t 


www.linuxvilag.hu 











[reguest] -5 /kereses.php 

[referer] —5 http://ww. jegyzet. com/ 

sz index .php 

[user-agent] -—5 Mozilla/4.0 (compatible; 
5MSIE 6.0; Win98) 


A példa a ,15-ös" látogató útvonalát mutatja: először lekér- 
te az index.php weboldalt, majd a kereses.php weboldalt. 
löbb kérése nem volt ennek a látogatónak. A példából kiol- 
vasható, hogy melyik honlapot milyen időpillanatban kérte 
le, mi volt a kéréshez tartozó referer, böngésző, kliens IP 
cím, stb. A következő folyamatok az ilyen tömbökből álló 
felhasználói útvonalak tömb alapján készítik el a speciali- 
zált modellt. 


Különböző útvonalak 

A felhasználói útvonalakban (3. ábra) keresi meg az azono- 
sakat (a bejárt weboldalak és sorrendjük azonos), ezen út- 
vonalakat összegzi. Lehetőség van arra, hogy egy paramé- 
terként megadott százalék alatti előfordulásokat eldobja, 

a viszonyítási alap a látogatók száma. Paraméterként meg- 
adható, hogy a megadott előfordulási százalék alatti útvo- 
nalak ne szerepeljenek az eredményben. 

A módszer a következő: a felhasználói útvonalak tömbjét 
végigolvasva minden felhasználó útvonala leképzésre kerül 
egy egyedi karakterláncba. A megegyező útvonalakat (sor- 
rend és többes látogatások is számítanak) bejárt felhaszná- 
lóknál ez az egyedi karaktersorozat azonos. A továbbiakban 
a létrejött egyedi útvonalleírók kerülnek összegzésre (meg- 
számoljuk, hogy egy egyedi útvonalat leíró karaktersoro- 
zatból hány van). 


Például: 


[/index.php] —5 3128 

[/index.php /eredmeny.php] -: 1016 

[/index.php /eredmeny.php /eredmeny.php] -5 386 
[/index.php /eredmeny.php /kereses.php] -—5 271 


A fenti példában látható, hogy csak az index.php fájlt 
összesen 3128 látogató nyitotta meg, ugyanakkor az 
eredmeny.php weboldalt már csak 1016-an nézték meg. 
A weboldal lekérések sorozata különálló, vagyis a példa 
első sora nem tartalmazza a második sorból az index.php 
weboldalra irányuló lekéréseket. 


Azonos oldalak egy látogatáson belül 

Hasonló a különböző útvonalak módszerhez, azzal 

a különbséggel, hogy az egyes weboldalak meglátogatási 
sorrendje nem számít. Itt is lehetőség van a nagyon ritka 
előfordulások elhagyására. 

A módszer (4. ábra) majdnem azonos a különböző útvo- 
nalak elkészítésének menetével. A különbség annyi, hogy 
itt a felhasználói útvonalakból az azonos weboldalra irá- 
nyuló többes lekérések összevonásra kerülnek (egyszer 
szerepelnek), illetve nem számít az egyes lekérések sor- 
rendje sem (ABC sorrendbe van rendezve a lekéréseket 
leíró karakterfűzér). 
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same pageű Létezik a különböző 


útvonalak tömbje? 


Van még útvonal? 





4. ábra Azonos oldalak egy látogatáson belül 
Például: 


[/index.php] -—5 3350 

[/eredmeny.php /index.php] -: 1947 
[/eredmeny.php /index.php /kereses.php] -:5 1392 
[/index.php /kereses.php] -—5 195 


Atkattintási idők 

Az egyes weboldalak közötti átkattintások számát, mini- 
mális, maximális, összes és átlagos idejét adja meg egy 
többdimenziós tömbben. Az átkattintásoknak irányuk van 
(forrás és cél), az eredményben külön van választva a két 
irány. Elsősorban az idő alapú látogató-elkülönítésnél fon- 
tos, az átlagos és maximális idők alapján lehet a megfelelő 
idő paramétert módosítani. Paraméterként megadható, 
hogy azok az átkattintások ne szerepeljenek az eredmény- 
ben, amelyek száma nem éri el a felhasználók számának 
megadott százalékát. 

A különböző átkattintási idők számítása (5. ábra) a fel- 
használói útvonalak vizsgálatával történik, az útvonal két 
lekérése közötti idők kerülnek vizsgálatra és összegzésre, 
átlagszámításra. 


Például: 


Array 
( 
[/index.php] -5 Array 
( 
[/eredmeny.php] -—5 Array 
( 

[clicks] —-5 3463 
[duration] -5 121315 
[avag dur] —5 35.03 sec 


A példa azt mutatja, hogy az index.php weboldalról össze- 
sen 3463 átkattintás történt az eredmeny.php weboldalra, 

a két weboldal lekérése között összesen 121315 másodperc 
telt el, amely adatokból már egyszerűen kiszámolható, 
hogy az index.php lekérése után átlagosan 35.03 másodperc- 
cel kérték le a felhasználók az eredmeny.php weboldalt. 
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Létezik útvonal tömb? 
Nem 


Van még 
útvonal? 


Van küszöbérték? 


5. ábra Átkattintási idők számítása 


A modellezés inkább az általános érvényű megállapításokat 
keresi, ezért itt is lehetőség van a ritka átkattintások elha- 
gyására, ezáltal egyszerűsítve a modell érthetőségét és átte- 
kinthetőségét. 


Be- és kilépő oldalak 

A belépő weboldalak egy portálon belüli weboldalhoz ad- 
ják meg, hogy honnan és hányszor nyitották meg (ezek kö- 
zött szerepel portálon belüli és kívüli forrás is). Ez az adat- 
sor az analízis során létrejön, mert egyszerűen előállítható 
az eseménynapló bejegyzésből a referer adatok használatá- 
val. A belépő oldalak statisztikája csak akkor állítható elő, 
ha a referer adatok léteznek az eseménynaplóban, ellentét- 
ben a kimenő oldalak statisztikájával, ami a felhasználók le- 
kérései alapján kerül összeállításra (útvonalban következő 
lekérés alapján), vagyis a legegyszerűbb szerkezetű ese- 


Eh 


ménynapló alapján is előállítható. 
Például: 


[/index.php] -5 Array 


( 
[-] —5 4979 
[http ://ww. oktaton.hu/index.php] -s 1355 
[http://ww.puska.hu/portal1.htm] —5 373 


[http://ww. lapkereso.hu/keres.php] -—5 350 


A fenti példában látható, hogy az index.php web- 
oldalra 4979 felhasználó érkezett referer adat nél- 

kül (ezt jelenti a ,-"). Ez jellemzően abban az esetben 
fordul elő, amikor a felhasználó egy új böngésző abla- 
kot nyit és annak címsorába maga gépeli be az adott 
portál elérhetőségét. 

A kilépő weboldalak ellenkezőleg működnek, mert itt azt 
vizsgáljuk, hogy egy adott weboldalról merre mentek to- 
vább a látogatók, ahol minden weboldal szigorúan az adott 
portálhoz tartozik. Ez a modell a felhasználói útvonalak 
elemzésével gyűjti össze az adatokat, megvizsgálja, hogy 
egy lekérés után melyik másik weboldal lett lekérve és 
összeszámolja az egyes párok előfordulásait (6. ábra). 





.analyze use cookie0 


web model out Létezik útvonal tömb? 


Nem 


Van még útvonal? 





Van még bejegyzés? Kérés elfogadható? 


7. ábra Különböző lekérések kigyűjtése 


Van 


kt [/feladas.php] — 54 
[/tajekoztato/?t-ismerteto] -5 15 

[/tajekoztato/] -—s 47 

[/tajekoztato/?t-szabalyzat] -—s 25 


Küszöbérték? 





6. ábra Kilépő oldalak statisztikák készítése ; ; 
Fenti példában a ,,-" jelentése: nem volt a felhasználónak 
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Például: további weboldal lekérése az index.php után, azaz távozott 
az adott portálról és az utolsó meglátogatott weboldala az 
Array index.php volt. 
( Mindkét esetben megadható az a százalékos paraméter, ami 
[/index.php] -—5 Array alatti előfordulásokat ki kell hagyni az eredmény tömbből. 
( 
[/eredmeny.php] —5 3774 Különböző kérések 
(z] ss 3751 Eltérően az eddig ismertetett analizáló és modellező alrend- 
[/kereses.php] -: 640 szerektől, ez a metódus inkább az előzetes eseménynapló 
[/index.php] -: 610 vizsgálatot segíti azáltal, hogy a megtalálható összes külön- 
[/reszlet.php] -— 97 böző kérést kigyűjti (7. ábra). Így megvizsgálható, hogy 
[/figyeles.php] -: 62 a tényleges modellezéshez mely lekérések (weboldalak) 


Latogasson el hozzank! 


Virtuális könyvesboltunk egyedülálló választékot kinál 
magyar és angol nyelvű számítástechnikai könyvekből. 
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használandóak. Más szemszögből megtudható, hogy egyál- 
talán mely weboldalakat kérték le a látogatók a szerverről. 
A függvény használja az eseménynapló bejegyzéseket szű- 
rő és egyszerűsítő folyamatokat, amelyek a konfigurációs 
fájlban akár ki is kapcsolhatóak. 

Paraméterként megadható, hogy a kérések egyszerűsítés 
után kerüljenek összehasonlításra, vagy minden kérést úgy 
vegyen a szoftver, ahogy a naplófájlban szerepel. 


Továbbfejlesztési lehetőségek 

A megvalósított analizáló szoftver elsősorban az algoritmu- 
sok és lehetséges modellek bemutatására készült, az alap- 
funkciókat biztosan képes nyújtani. A fejlesztés során felme- 
rült továbbfejlesztési lehetőségek ismertetése következik. 


Gyorsítás, nagyméretű eseménynaplók feldolgozása 

A első fontos fejlesztési lépés a szoftver működésének gyor- 
sítása, amely összefügg a nagyméretű (200 MB feletti) ese- 
ménynaplók feldolgozásával. A szoftver jelenleg a teljes 
adatstruktúrát (felhasználói útvonalak) memóriában tárolja, 
ami legalább annyi memóriát igényel, mint a feldolgozandó 
eseménynapló mérete. 

lekintve, hogy már egy közepes forgalmú portálon is 
akár napi néhány száz megabyte eseménynapló keletke- 
zik, megoldandó, hogy ne kelljen az egész struktúrát 

a memóriában tárolni. Elég volna csak azokat a felhaszná- 
lói útvonalakat megtartani a memóriában, amelyek az ép- 
pen elemzett eseménynapló bejegyzés feldolgozásakor 
még számításba jöhetnek, mint olyan felhasználói útvo- 
nal, amelyhez az adott kérés hozzácsatolható (beilleszthe- 
tő a látogató útvonalába). A figyelembevétel eldöntését 
megkönnyíti, hogy mind a munkamenet azonosító al- 
kalmazása, mind az idő alapú látogató elkülönítés esetén 
behatárolt, hogy milyen időintervallumban beérkezett 
eseményeket (naplóbejegyzéseket) kell még memóriában 
tárolni. Mivel a webszerver a munkamenet azonosítók 
érvényességét ugyanúgy idő alapján figyeli, mint ahogy 
a látogatókat a lekérések időkülönbsége alapján elkülönít- 
jük, ezért adható meg a szerver beállításának ismeretében 
a fenti intervallum. 

Mivel a további feldolgozások a felhasználói útvonalakat 
használják, ezért célszerű például egy adatbázisba tölteni az 
analizálás során keletkező útvonalakat. Így a további mo- 
dellkészítési lépések is gyorsíthatóak az adatbázis kezelő 
rendszerek optimalizálásával. 


XML alapú konfiguráció 

A fejlesztés során egyértelművé vált, hogy az eddig elter- 
jedt konfigurációs fájl struktúra nem alkalmas akármilyen 
beállítás tárolására. Főleg a szöveges és speciális karakterek, 
tömbök kezelésre nem alkalmas. 

Mivel az egyes eseménynapló fájlok szerkezetileg egyediek 
is lehetnek, ezért lehetőséget kell biztosítani a reguláris kife- 
jezések eseménynaplóhoz kötéséhez (vagyis a konfiguráci- 
ós fájlban kell tudni megadni). 

A XML alapú konfiguráció további előnye a csoportosít- 
hatóság több mint két szint mélységben is. Így kényelme- 
sebbé tehető a tömb jellegű adatstruktúrák megadása, 
pontosabban leírható már a címkékkel is az egyes elemek 
jelentése és célja. 
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Az XML fájlok feldolgozása még nem teljesen kiforrott 

a PHP esetében, de már vannak használható és gyorsan al- 
kalmazható megoldások, kiegészítések is, amelyek tudása 
olykor még korlátozott, vagy egyedi fejlesztést igényel. 


Kereső robot a referer alapú vizsgálathoz 

A referer alapú vizsgálathoz szükséges, hogy az adott 
portálra vonatkozóan az egyes weboldalak között az 
összes átjárási lehetőséget megadjuk. Nagyobb, rendsze- 
resen bővülő portálokon (például áruház, hírmagazin) 
ennek még az időszakosan történő megadása is igen 
komoly munkát igényel. 

A referer alapú vizsgálathoz kifejleszthető egy (általánosan 
is használható) úgynevezett crawler (kereső robot), amely 
automatikusan végigjárja a portál összes oldalát, kigyűjtve 
az összes linket, rendszerezve az átjárási lehetőségeket. 
Jelenleg elterjedt portál navigációs és hirdetési jelleg- 
zetesség, hogy minden weboldal (funkció) elérhető 
minden weboldalról, vagy a linkek dinamikusan (adott 
tartalomhoz, hírhez kapcsolódóan, napszaktól függően, 
vagy véletlenszerűen) látogatásonként változóan kerül- 
nek ki egy-egy weboldalra. Fentiek miatt a kereső robot 
igazán csak olyan esetekben tud jól segítségünkre lenni 
az átjárási lehetőségek begyűjtésében, ahol a portál 
szerkezete viszonylag fix, jól elválasztott navigációs 
struktúrák vannak. 


XML és grafikus kimenetek 

Az elkészült analizáló szoftver jelen formájában egy 
prototípusnak megfelelő kimenetet produkál, amelynek 
megértése erősen feltételezi a szoftver és a modellek 
ismeretét. 

A modellek további feldolgozására (például egyedi meg- 
jelenítés, beillesztés más programba) ma az a legkézen- 
fekvőbb és legjobb kompatibilitási megoldás, ha az 
eredményeket előre definiált szerkezetű XML fájlba 

is ki lehet menteni. 

A megértést és szemléltetést könnyítheti meg, ha az ered- 
mények grafikus formában jelennek meg (például oszlop- 
diagramm, gráf, folyam). Ez segítheti a nem szakértőket 

a szoftver mélyebb ismerete nélkül is a megfelelő döntés 
(szerkezet, navigáció, tartalom, stb. módosítása) meghoza- 
talában, az analizálás eredményeinek és jelentőségének 
felismerésében. 


Osszefoglalás 

Jelen cikkben egy konkrét modellező szoftver működé- 
sét vizsgáltuk meg, külön kitérve az egyes algoritmikus 
kérdésekre. 

Következő cikkemben a most bemutatottak alapján 
néhány konkrét példán keresztül szemléltetem, hogy 
mik a felhasználói viselkedés vizsgálatának gyakorlati 
eredményei. 


Beszédes Balázs (beszedes(dei.hu) 

24 éves, az e-Médila Informatikánál mérnök- 
informatikus. Hobbija a kerékpározás és 

a kirándulás. 





Samba - Windowsban is otthon (1. rész) 


Néhány hónapja az eWeek egyik szerzője arra a következtetésre jutott, hogy 
a Sambát futtató linuxos kiszolgálókat Immár nem egyszerűen a Windows rend- 
szerekkel való együttműködésre célszerű használni, hanem magának a Windows 


2003 Servernek a kiváltására... 


apjainkban szerte a médiában azt lehet olvasni, 
Mi azt hallani, hogy a nyílt forráskódú rendszerek, 
ezen belül a Linux alapú rendszerek mindenki 
— vagy legalábbis majdnem mindenki - nagy örömére 
egyre nagyobb népszerűségnek örvendenek. A böngé- 
szők terén a Firefoxnak sikerült elérni azt, amit nagyon 
régóta senkinek, 909 alá szorította az Internet Explorer 
használtságát. Ez ugyan kicsit fanyar humornak is beillik, 
de a lényeg, hogy talán megmozdult valami, talán végre 
verseny lesz, amiből pedig egy fél kerülhet ki nyertesen, 
a felhasználó. 
A kiszolgálók területén talán a fentinél jobb a helyzet, 
a verseny sokkal kiegyenlítettebb, a Linux népszerű, sőt 
egyre népszerűbb. Viszont hiába használunk a kiszolgá- 
lónkon Linuxot, ha minden kliensünk Windowst használ 
és az általunk nyújtott szolgáltatásokat adott esetben vagy 
nem tudja igénybe venni, vagy egyszerűen csak hasznát 
nem tudja venni. De ne keseredjünk el, ne essünk pánik- 
ba, mert mint mindenre, erre is van megoldás. Úgy hívják, 
hogy Samba. 
A Samba egy windowsos kliensek kiszolgálására alkalmas 
rendszer, amely amellett, hogy állomány- és nyomtatómeg- 
osztást kínál, ennél sokkal többet tud. Alkalmas Windows 
NT rendszetű tartományvezérlésre, Windows profilok létre- 
hozására és tárolására, házirendek készítésére és alkalmazá- 
sára és szinten mindenre, amit egy windowsos munkacso- 
portos kiszolgálótól elvárunk. 
Cikksorozatomban ezeket a funkciókat vesszük szem- 
ügyre, nézzük meg, hogy mely szolgáltatás milyen módon 
érhető el. 





A telepítés 

Kezdjük az elején, tegyük fel a csomagokat. Illetve, mie- 
lőtt feltennénk a csomagokat nézzük meg, hogy milyen cso- 
magok vannak és ezekből miket szeretnénk telepíteni. 

A Samba kiszolgálóból jelenleg két fő verzió érhető el, 

a 2.2.x és a 3.0.x verziók. Ebben a cikkben a 3.0-s verziót és 
annak szolgáltatásait tárgyaljuk, úgyhogy javaslom ezen 
verzió telepítését. Ugyan a főbb pontokban a 2.2 és 3.0 tele- 
pítése és beállítása hasonló, ám a 3.0 több olyan új szolgál- 
tatást is tartalmaz, ami a 2.2-ben még nincs jelen. 
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Samba kiszolgáló a legtöbb Linux és Unix terjesztésre elér- 
hető bináris formában, tehát a dolgunk nem több, mint 

a megfelelő csomagot letölteni és telepíteni. Általában 

a Samba majd" minden terjesztésben elérhető az adott 
disztribúció csomagkezelőjén keresztül, de ha nem talál- 
nánk, akkor a www.samba.org weboldalról letölthető több 
tucat különböző kiadás. 

Én egy Debian Sarge kiszolgálóra telepítettem a csomago- 
kat, teljesen egyszerűen az apt forrásból elérhető verziókat. 
Javaslom továbbá telepíteni a swat csomagot, amely egy 
webes alapú konfigurációs eszköz a Samba beállításához. 


Az első lépések 

Ha megtörtént a telepítés, akkor nézzük, hogy mit és hol 
találunk. A legfontosabb talán az /etc/samba könyvtár, 
ugyanis a Samba az összes beállítását ebben a könyvtárban 
tárolja — bár ez terjesztésenként esetleg változó lehet, de 
egy kis logikával könnyen meg lehet találni a megfelelő 
könyvtárat. A másik fontos könyvtár, illetve állomány 

az /etc/init.d/samba. Ezzel a szkripttel lehet a kiszolgáló 
démont indítani és leállítani. 

Miután telepítettük a kiszolgálót, a szamba könyvtárban talá- 
lunk egy smb.conf állományt. Ez az állomány tárolja a ki- 
szolgáló beállításait, amennyiben változtatni kívánunk 

a rendszeren, azt itt kell megtenni. A másik fontos állo- 
mány a samba könyvtárban az smbpasswd, ugyanis ebben 
a fájlban kerülnek tárolásra a Samba által beregisztrált fel- 
használók és a hozzájuk tartozó jelszavak. Ezt az állományt 
az smbpasswd parancs használatával tudjuk kezelni. Így le- 
het új felhasználót hozzáadni, jelszót cserélni és hasonló 
adminisztrációs műveleteket elvégezni. 


Az smb.conf 

Nézzük akkor, hogy miből áll az smb.conf állomány, milyen 
részekre oszlik, azoknál milyen beállítási lehetőségeink van- 
nak. Első nekifutásra egy nagyon egyszerű beállítást né- 
zünk meg, majd ezt bővítjük a későbbiekben. 

Az első bekezdés az smb.conf állományban a [global], te- 
hát a globális beállítási opciók listája. Itt olyan beállításokat 
tehetünk, amelyek a teljes kiszolgáló entitásra vonatkoznak, 
bár ezek egyes paramétereit a későbbiekben az egyes kiosz- 
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tások beállításánál felül írhatjuk. Nézzünk egy egyszerű 
beállítást és nézzük meg lépésről-lépésre, hogy mi mit is 
jelent. Ha ezen túl vagyunk és működnek a beállításaink, 
akkor elkezdjük a rendszert bővíteni és felruházzuk min- 
den jóval, amit a Samba kínál. 

A whorkgroup változó értékének azt a csoport, vagy tarto- 
mány nevet kell megadni, amiben szeretnénk a kiszolgálót 
üzemeltetni. A server string változó értéke egy szabadon 
választott karaktersorozat, amelyet a kiszolgálónk nevének 
adhatunk meg. Ez most jelenleg a $hosztnév server 
(Samba $verzió szám) lesz. 

Amennyiben szeretnénk a kiszolgálót WINS szerverként 

is üzemeltetni, amihez Win9x-es gépek kiszolgálásához 
szükségünk lehet, akkor adjuk a wins support változónak 
a yes értéket. 

A dns proxy változóval állíthatjuk, hogy az nmbd démon 

a gépek NetBIOS nevének visszakeresését a DNS-ben is 
megpróbálja vagy sem. Ennek az alapértelmezett beállítása 
no, úgy gondolom, hogy kezdetnek ez tökéletesen megfelel, 
hacsak nincs olyan DNS kiszolgálónk, amely ezt a művele- 
tet támogatja. 

A name resolve order azt mutatja, hogy a gépek nevének 
visszafejtéséhez melyik adatbázisokat milyen sorrendben 
használjuk. 

A 1og file változónak megadhatjuk, hogy a Samba hová 
helyezze el a saját naplóállományát. Amennyiben nem tet- 
szik az alapértelmezett beállítás, nyugodtan cseréljük ki. 

A max 1og size változó értékének megadhatjuk kilobájtban 
kifejezve a naplóállomány maximális méretét. A sys109- 0 
azt szimbolizálja, hogy a Samba ne a /var/log/syslog állo- 
mányban, tehát nem a rendszernaplóban helyezi el saját 
bejegyzéseit. Amennyiben mégis erre volna szükségünk, 
akkor változtassuk 1-re az értéket. 

A security változó már egy érdekesebb opció, ennek a be- 
állításaival már érdemes esetleg játszadozni. Nálunk a beál- 
lítás a user szint, ami annyit tesz, hogy a felhasználók azo- 
nosítását az snbpasswd, vagy az aktuálisan beállított fel- 
használói adatbázis alapján a kiszolgáló végzi. Amennyiben 
a share értéket adjuk meg, úgy egy egyszerű, jelszó hitele- 
sítés nélküli hozzáférést teszünk lehetővé a rendszerben. 
Amolyan Windows9x stílusban — megosztunk mindent, az- 
tán akinek van megfelelő nevű felhasználója látja a teljes 
tartalmat. Amennyiben a domain beállítást választjuk, úgy 
a kiszolgáló a felhasználót az aktuális tartományvezérlő fel- 
használói adatbázisából fogja hitelesíteni. Ez akkor jó meg- 
oldás, ha a szervert egy Windows tartományhoz csatolt ki- 
szolgálóként kívánjuk üzemeltetni. A security - server 
beállítással elérhetjük, hogy a kiszolgáló entitás egy másik 
megfelelően beállított SMB kiszolgáló(legy Samba vagy NT 
kiszolgáló) adatbázisa alapján azonosítja és hitelesíti a fel- 
használót. Amennyiben nem található használható kiszol- 
gáló az azonosításra, úgy a Samba megpróbál a security - 
user metódus alapján beléptetést végezni. Végezetül érde- 
mes megemlíteni az ADS beállítási lehetőséget, amellyel 
Windows Active Directory Server támogatásával tudunk fel- 
használói hitelesítést végezni. Fontos azonban megjegyezni, 
hogy ezt az opciót használva a kiszolgálót nem fogjuk tud- 
ni Active Directory kiszolgálóként üzemeltetni sőt, a Samba 
egyáltalán nem képes, még LDAP támogatással sem AD ki- 
szolgálóként működni! 
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Az encrypt passwords változót állítsuk true értékre, 
ugyanis ez a változó azt a beállítást hivatott elvégezni, mi- 
szerint a jelszavak a klienssel való egyeztetés során kódolt 
formában kerüljenek közlésre. Ez egyfelől mindenképpen 
ajánlott az esetleges biztonsági kockázatok elkerülése vé- 
gett, másfelől a Windows ügyfelek NT 4.0 SP3 és a Windows 
98 óta ezt a beállítást használják alapértelmezettként. 

(Ezt a Windows registry-ben ugyan ki lehet kapcsolni, 

de ez egy nem támogatott konfiguráció.) 

A passdb backend szintén egy érdekes beállítási lehetőség. 

Itt tudjuk megadni, hogy milyen adatbázis alapján történjen 
a felhasználói hitelesítés. Ez alapértelmezésben az smbpasswd 
állomány, de akár használhatunk LDAP, vagy MYySOL alapú 
adatbázist is. Ezekről még a későbbiekben ejtünk szót, most 
hagyjuk az alapértelmezett smbpasswd értéken. 

A következő érdekesebb beállítás a unix password sync. 
Ezt a jelzőt állítva tudjuk megadni, hogy történjen-e egyez- 
tetés a UNIX passwd és az smbpasswd állományok tartalma 
között, amennyiben a kódolt SMB jelszó megváltozik az 
smbpasswd állományban. Amennyiben true értéket adunk 
meg, úgy a beállított passwd program változó szerinti 
szkript a root felhasználó jogaival történő futtatásával felül- 
írásra kerül a beállított UNIX jelszó a rendszerben. 

A printing beállításra akkor lehet szükségünk, amennyi- 
ben a Sambán keresztül szeretnénk nyomtatókat is megosz- 
tani a hálózatban. Ez a paraméter írja le, hogy a nyomtató 
állapotinformációit milyen interpretáció alapján kell feldol- 


gozni. Alapbeállítás az LPR, vagy BSD, de amennyiben pél- 
dául CUPS alapú nyomtatást használunk, úgy a cups érték 
megadása az ajánlott. A nyomtatás beállításaival a későbbi- 
ekben még bővebben foglalkozom. 

Az általános beállításaim között az utolsó fontosabb 

a domain master paraméter beállítása. Ez az érték írja le. 
hogy a Samba kiszolgáló a kiszolgált tactományban, mun- 
kacsoportban a master browser szerepét felvegye-e, vagy 
sem. Az alapértelmezett érték az auto. Amennyiben min- 
denképpen ezt a gépet szeretnénk dedikálni a hálózatban 
master browser-nek, úgy állítsuk yes értékre. Megjegyez- 
ném, hogy Windows NT Primary Domain Controller-ek elő- 
szeretettel ragadják magukhoz ezt a feladatot, így amennyi- 
ben egy NT PDC-vel rendelkező hálózatban ezt az értéket 
yes-re állítjuk és az NT PDC később csatlakozik a hálózat- 
hoz, mint a Samba kiszolgáló, úgy a két rendszer össze- 
akadhat. 

Ezzel a globális beállítások végére is értünk. Hangsúlyoz- 
nám, hogy ezek tényleg csak alapvető beállítások, ezzel 
egy működő, de meglehetősen egyszerű rendszert hoz- 
tunk létre. A Samba ennél lényegesen többet tud és ezeket 
végig is fogjuk nézni. 

Most következzen a megosztások beállítása, elsőnek 

a rendszerben jelen lévő UNIX felhasználók home könyv- 
tárának a kiosztása. 


[homes] 

comment - Home Directories 
browseable - no 

writable — yes 

create mask - 0700 
directory mask - 0700 


Ezzel a beállítással elértük azt, hogy amennyiben egy olyan 
felhasználó csatlakozik a Samba kiszolgálóhoz, akinek van 
UNIX felhasználója is, úgy a saját és mindig csak a saját 
home könyvtára kiosztásra kerül. Ez egy nagyon egyszerű 
és jó megoldás az alapvető felhasználónként elkülönülő 
fájlmegosztási szolgáltatás biztosítására. 

A két mask beállítási opció természetesen a fájl és könyvtár 
létrehozásra vonatkozóan azt mutatja, hogy a kiszolgálón 
milyen UNIX jogokkal kerüljenek az adott állományok lét- 
rehozásra. 


[printers] 

comment - AI] Printers 
browseable - no 

path - /tmp 

printable — yes 

public -— no 

writable - no 

create mode - 0700 


A printers bekezdésben a rendszerben megosztott nyom- 
tatók beállítása történik, ebben a mappában kerülnek majd 
közzétételre a megosztott nyomtatók. Ezt az opciót a nyom- 
tatómegosztás kapcsán részletesen fogom majd tárgyalni. 


[pub] 


comment - Samba server!"s PUB directory 
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writable -— yes 
locking - no 
path - /pub 
public -— yes 


Végül, de nem utolsó sorban nézzünk egy olyan megosz- 
tást, amelyet minden felhasználó látni fog a rendszerben, 
amelyben közös állományok kerülhetnek elhelyezésre. 

A fenti beállítással egy írható, minden felhasználó által lát- 
ható kiosztást hoztunk létre, amely a /pnub mappára mutat 
a UNIX fájlrendszeren. 

Ezzel az alapvető beállításokat el is végeztük, már 

csak annyi dolgunk van hátra, hogy a Samba felhaszná- 
lóinkat létrehozzuk, illetve a felhasználókhoz jelszava- 
kat állítsunk be. Amennyiben új felhasználót kívánunk 
a rendszerhez adni, úgy az smbpasswd -a user paran- 
csot használjuk, amennyiben pedig a felhasználó jelsza- 
vát szeretnénk megváltoztatni, úgy az smbpasswd user 
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parancsot. 

A kiszolgáló elindítása után ejtsünk néhány szót olyan 
linuxos segédprogramokról, amelyekkel a Samba, vagy 

a Windows hálózati megosztásait tudjuk kezelni. 

Az egyik legfontosabb ilyen segédprogram gyűjteményt 
Debian alatt az smbclient csomag tartalmazza. Ezek olyan 
parancssoros eszközök, amelyek segítségével SMB proto- 
kollt támogató gépeken végezhetünk le lekérdezéseket 
(smbclient), küldetünk parancssorból nyomtatási paran- 
csot (smbspool), valamint megnézhetjük például a hálózati 
struktúrát (smbtree). 

Amennyiben Samba, vagy Windows kiszolgálók megosztá- 
sait szeretnénk használni, úgy az smbfs csomag telepítésére 
lesz szükségünk. Ez a csomag tartalmazza a Samba állo- 
mányrendszer becsatolásához szükséges eszközöket. 
Amennyiben telepítjük a csomagot, akkor a mount parancs- 
nak a -t kapcsolóval smbfs értéket adva be fogunk tudni 
Windowsos megosztásokat csatolni a UNIX fájlrendszerbe. 
Amennyiben szeretnénk ilyen megosztásokat rendszeresen 
használni, úgy érdemes ezt a bejegyzést elhelyezni az 
/etc/fstab állományban, ahol a fájlrendszer típusának szin- 
tén az smbfs-t kell megadni. 

Nézzünk egy egyszerű példát: 


mount -t smbfs -o 
username-viktor , passw ord-MyPassword 
sz //myServer/viktor /mnt/tmp/ 


Ezzel a paranccsal a myServer kiszolgáló viktor kiosztását 
a viktor felhasználó jogaival az /mnt/tmp könyvtárba 
csatoljuk be. 

Ezzel a sorozat nyitó cikkének végére is értünk. A folytatás- 
ban megpróbáljuk a Samba minden mélységét meghódíta- 
ni. Érdemes lesz figyelni, mert egy nagyon hasznos eszközt 
kapunk egy jól beállított Sanba személyében. 


Illés Viktor (viktor2ei.hu) 

23 éves, a BME műszaki informatikus szakának 
hallgatója, mellette weblapokkal, linuxos 

és windowsos rendszerekkel foglalkozik. 
Szabadidejét legszívesebben a szabadban tölti, 
teniszezik és kerékpározik. 
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FreeBSD - a szomszéd vár 44. rész) 


Egy munkaállomás felépítése. 


egtöbbünknek van saját számítógépe, amelyet több- 
L nyire rendszeresen használunk a mindennapi élet- 

ben: elektronikus leveleket fogalmazunk és olvasunk, 
turkálunk a világháló távoli bugyraiban, hivatalos leveleket 
írunk meg s nyomtatunk ki, esetleg táblázatokat-adatbáziso- 
kat hozunk létre, illetve néha játszunk vagy filmet nézünk. 
A saját géptermünkben rendszergazdák és felhasználók va- 
gyunk egy személyben. A hiedelmekkel ellentétben — ava- 
tatlan szem számára -— a , vár díszterme" pont úgy néz ki, 
mint a vendégeké... nézzünk tehát a díszletek mögé. 


A grafikus felület 

Bár az igazi UNIX felhasználó egy szöveges konzolon min- 
den felmerülő problémát meg tud oldani, valljuk be: jól jön 

a grafikus felület, amely természetesen FreeBSD esetén is ren- 
delkezésre áll. Ialán nem okoz meglepetést, ha a jó öreg 
X11R6 felülettel találkozunk, azonban a konkrét implementá- 
ció a megszokott XFrees86 helyett már itt is az új kiadás: 

az X.org lesz (meg kell jegyeznek, hogy a FreeBSD verzió- 
számozása egy kis késéssel szokta követni a Linux alatt meg- 
jelenő verziókat, hiszen át kell alakítani egy kicsit, hogy 

a FreeBSD rendszermaggal együtt tudjon működni). Ennek 
megfelelően a beállítás és a használat teljesen azonos módon 
történik, mint egy átlagos Linux esetén. Különbség abban le- 
het, hogy némely Linux terjesztő saját programot készít a gra- 
fikus felület automatikus beállítására, amely jelentősen segít 

a kezdő felhasználónak -— ezt FreeBSD esetén mellőznünk kell. 
Alapvetően két úton tudjuk beállítani az X.org programot, 
az egyik nehézkes, a másik járhatatlan. Iradicionális mód- 
szer az xorgconfig használata, amely szöveges módban 
fut, s olyan kérdéseket képes feltenni, amelyek megválaszo- 
lásába még egy jól felkészült informatikus mérnök is bele- 
sülhet. Ezért aztán az xorgcfg programot szoktuk használ- 
ni, mivel ez képes felderíteni a gépünkben lévő videókártya 
típusát-jellemzőit, majd ez alapján már grafikus felületen 
tudjuk a beállításokat eszközölni; a használata viszonylag 
egyszerű, bár kényelemben messze van az ideális állapottól. 
Létezik egy harmadik út is, amely egy kis csalással sok ne- 
hézségtől tud megkímélni minket: ha a gépünkön van már 
Linux rendszer, akkor egyszerűen csak át kell másolni az 
XF86Config nevű állományt a /etc/X11/ könyvtárba, ahol 
majd az X.org keresni fogja, és nagy valószínűséggel mű- 
ködni is fog ezen állomány alapján. Azért csak valószínűleg, 
mert előfordulhat, hogy a videókártyát nem az X.org támo- 
gatja, hanem a gyártó ad Linux meghajtóprogramot a kár- 
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tyához, s ekkor -— többnyire — nem tudjuk teljes mértékben 
kihasználni a kártya tudását. Általában ez a hardveres 3D 
gyorsítást érinti, amelyet mellőznünk kell, ha nem NVidia 
kártyánk van. Ezt a kivételt azért említem meg, mert az 
NVidia ezidáig az egyetlen gyártó, amely nemhogy a Linux 
rendszert, hanem a FreeBSD-t is támogatja saját készítésű 
rendszermag modullal. 

Sokan nem is szembesülnek a gyártó által adott támogatás 
hiányával, hiszen nem tudják, miből maradnak ki, ezért ír- 
nék néhány példát, amire képesek leszünk FreeBSD alatt az 
NVidia modult használva (természetesen ugyan ezek hasz- 
nálhatók Linux esetén is). Az X.org önmagában nem igazán 
kezeli a kártyák TV kimenetét, illetve nem mindig kapunk 
megfelelő minőségű képet. A IV kimenet használatához 

az XF8ő6Config állományt kell szerkeszteni, mégpedig 

a Section , Device" résznél kell a vége felé beilleszteni 

a következő sorokat: 


Option "TWwinVview" true" 

Option "Twinvieworientation" "Clone" 

Option "MetaModes" "1024x768,1024x768" 
Option  "SecondMonitorHorizSync" "607 
Option "SecondMonitorVvertRefresh" 550-707 
Option "CconnectedMonitor" éTV, CRT" 


Az X kiszolgálót újraindítva meg fog jelenni a IV képer- 
nyőn is a monitoron látható kép. Sajnos munkára nem 


lehet használni a IV kis felbontása miatt, viszont filmek 

— élvezhető — megtekintésére annál inkább. Lehetőségünk 
van a Dual View kihasználására is, amely lehetővé teszi két 
monitor egyidejű használatát. Ehhez olyan videókártya 
kell, amelynek két monitorcsatlakozása van, vagy egy átla- 
gos laptop is megteszi, amelyekben az NVidia vezérlő több- 
nyire tudja ezt a működési módot. Otthoni körülmények 
esetén kevéssé használható, viszont az oktatásban látom 
nagy előnyét, hiszen így egy kivetítővel sokkal kényelme- 
sebb a munka. A munkaasztal ezáltal méretben megduplá- 
zódik (beállítás függvénye, hogy magasabb vagy szélesebb 
lesz), így kétszer akkora helyünk lesz, mint eddig, és ebből 
a hallgatók csak az egyik részt látják. A kivetítőn futhat 

a bemutatott program, vagy a prezentáció, a munkaasztal 
másik részén pedig a előadás következő fázisának előkészí- 
tése, vagy egy új program indítása történhet, s ezt nem lát- 
ják az előadás résztvevői. Ezáltal sokkal rugalmasabb és 
szebb lehet az előadás. Ehhez egyszerűen csak a fent leírt 
részt kell egy kicsit átszerkeszteni: 


Option "Twinview" true" 

Option "Twinvieworientation" "Rightof" 

Option "MetaModes" "1024x768,1024x768" 
Option  "SecondMonitorHorizSync" "30-68" 
Option "SecondMonitorVertRefresh" 550-707 
Option "CconnectedMonitor" "DFP, CRT" 


Miután szükségeinknek megfelelően beállítottuk, és sikere- 
sen el is indítottuk az X felületet, már csak a megszokott 
ablakkezelő felület feltelepítése van hátra, amelyek közül 

a ,nagyok" minden bizonnyal, de a , kicsik" nagy része is 
többnyire telepíthető a ports adatbázisból; sajnos a verziók 
szintén egy kis késéssel jelennek meg. A többségünk KDE-t 
vagy GNOME-ot használ, jelenleg a 3.3.2 verzió telepíthető 
a KDE ablakkezelő rendszerből, illetve a GNOME 2.8.1 is 
elérhető már (bár mire e sorokat újságban olvassuk, már 

a GNOME 2.8.2 is elérhető lesz). Mind a két ablakkezelő 
rendszer szinte összes funkciója azonos módon használha- 
tó, mint Linux esetén, esetleg egy-két hardverközelibb 
(például az APM vagy az ALCI kezelése laptopok esetén) 
segédprogram működése azért akadozhat, hogy azért ne 
legyen olyan szép a kép... 


$1!/bin/sh 

case $1 in 

start) 
/usr/local/bin/kdm 


esac 


Kezdők számára problémát okozhat, hogy (például) a felte- 
lepített KDE nem fog önmagától elindulni, mint ahogy 

a grafikus felület sem, ezt minden esetben nekünk -— mint 
rendszergazdának - kell megtennünk, parancssorban kiad- 
va a kdm parancsot. Ezt természetesen akár automatizálhat- 
juk is, ez lényegében egy egyszerű programocska készítését 
jelenti, amelyet a /usr/local/etc/rc.d/ könyvtárba kell elhe- 
lyeznünk, a neve lehet kdestart. sh, a tartalma pedig a fent 
látható néhány sor (ne felejtsünk el futtatási jogot is adni 
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erre az állományra, különben nem fog induláskor lefutni). 
Ennek hatására a KDE bejelentkezés-kezelője — a KDM — 
fog elindulni, s ezzel már bármilyen telepített ablakkezelőt 
el tudunk indítani, illetve a ftelhasználóink is könnyebben 
képesek a gépet használni. Más bejelentkezés-kezelőre is 
könnyedén át lehet írni a kis programot, egyszerűen meg 
kell keresni a megfelelő állományt, amely indítja azt. 


A hany 

A hangkártya már minden számítógép szerves tartozéka, 
szinte már nem találunk olyan munkaállomásnak szánt 
alaplapot, amelyben nem található integrált hangvezérlő. 

A FreeBSD szinte az összes kommersz célra szánt hangkár- 
tyát (jobban mondva a vezérlő lapkát) ismeri, képes azt 
használni. Ez azonban csak egy szűk körét jelenti a forga- 
lomban lévő eszközöknek - gondolok itt elsősorban a mo- 
dern 5.1 kimenettel bíró házimozi rendszerekkel együttmű- 
ködni képes kártyákra — amelyeket még Linux alatt is csak 
nehézkesen vagy egyáltalán nem tudunk használni. Ebben 
az ügyben tehát a csodát ne a FreeBSD rendszertől várjuk, 
az is nagy öröm, ha sikerül egy olyan hangkártyából hangot 
csiholni, amely már Linux alatt bizonyított. 

Alapvetően az összes szükséges modul rendelkezésre áll, 
csak azt kell betöltenünk, amelyik a kártyát kezelni fogja. 
Ezt a tevékenységet ésszel vagy erővel tudjuk végezni. Az 
első módszer szerint megpróbáljuk kideríteni, hogy a kár- 
tyán milyen lapka van, és a modul nevéből kikövetkeztet- 
jük, hogy kezeli-e esetleg. A használható modulokat 

a /boot/kernel/ könyvtárban találjuk meg, akár ki is listáz- 
hatjuk snd " .ko mintára illeszkedő állományokat. A modul 
betöltése például a klidload snd ich parancs kiadásával 
történik. Ha inkább a nyers erő mellett szavaztunk volna, 
akkor az előbb említett könyvtárban kiadott kldload 

snd ".ko parancs is sikerhez vezethet, ekkor ugyanis az 
összes modult betöltjük: valamelyik csak kezeli a gépünk- 
ben található kártyát. 

Ha sikeresen eltaláltuk a kártyára szerelt lapka típusát, 

s a rendszermag is képes volt megfelelően kideríteni a mo- 
dulhoz rendelhető hardverértékeket (I/O, IRO, DMA), ak- 
kor a mag üzenetei között meg kell látnunk a kártya beje- 
lentkezését (ezt a dnmesg parancs kiadásával láthatjuk, illetve 
az első konzolra is kiíródnak ezek a szövegek): 
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pcmO: cIntel ICH3 (82801CAJ)5 port Oxcdc0-Oxcdff, 
5 0xce00-Oxceff irg 11 at device 3 

1.5 on pci0 

pcmO: [GIANT-LOCKED] 

pcmO: cYamaha YMF753 AC97 Codecs 


Minden más - nem ehhez hasonló - üzenet azt jelzi, hogy 
az áhított zenekar nem vállal egyszerű fellépést a vár dísz- 
termében... :( 


Az USB támogatás 

Két éve senki sem gondolta volna, hogy az USB ekkora kar- 
riert fog befutni, s manapság már szinte mozdulni sem lehet 
USB támogatás nélküli géppel. Gondoljunk csak a flopi- 
lemezeket felváltó az USB , kulcstartóra", amely fizikai mé- 
retben sokkal kisebb, tárkapacitásban viszont sokkal tágabb 
, elődjénél". A FreeBSD alapvetően támogatja az alaplapi 
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USB lapkákat, legyen szó az USB 1.1 vagy az USB 2.0 kiadá- 
sokról; ellenben az USB eszközök egy részét nem tudjuk 
még életre kelteni, bár határozott fejlesztőmunka van ezen 
a téren is. Az USB tárolók nagy hányada támogatott, csatla- 
koztatva a megfelelő helyre a rendszermag üzenetei között 
meg kell látnunk a következő üzenethez hasonlót: 


umassO: USB 2.0 Flash Disk USB Mass Storage Device, 
ssrev 2.00/0.01, addr 3 
da0 at umass-simO bus 0 target 0 lun 0 


da0: cUSB 2.0 Flash Disk PROL3 Removable Direct 
s Access SCSI-0O device 
da0: 1.000MB/s transfers 
da0: 125MB (256000 512 byte sectors: 64H 325/T 125C€) 


a at 


A létrejövő /dev/da0 eszközt - a rajta lévő fájlrendszernek 
megfelelően - tudjuk felcsatolni, s írni-olvasni a tárterüle- 
tet. A fájlrendszer kiderítése empirikus módszerekkel is le- 
hetséges, de javaslom a disktype használatát, amely meg- 
mondja egy tetszőleges eszközről, hogy milyen fájlrend- 
szert találunk rajta: 


$ disktype /dev/ad0Os2 


—- /dev/ad0Os2 
Character device, unknown size 
Ext2 file system 
UUID 222F5SDOC-FOBD-4D33-8491-347734D/DFBB 
s (DCE, v4) 
volume size 10.00 GiB (10742214656 bytes, 2622611 
blocks of 4 KiB) 


A digitális tényképezőgépek támogatottsága kicsit felemás. 
Amelyek képesek USB Storage módban működni, azok 
probléma nélkül csatlakoztathatók FreeBSD alatt is, amelyek 
csak a saját programjukkal értik meg egymást, azok nagy 
része a gphoto2 csomaggal lesz használható. A fennmaradó 
néhány típust sajnos nem tudjuk majd használni. 

Gyakori, hogy USB-IDE átalakítón át csatlakoztatunk IDE 
eszközöket a gépünkre. Ennek főleg hordozható gépek ese- 
tén van értelme, például egy DVD-írót tudunk ilyen módon 
egy laptophoz csatlakoztatni (amely például nem tartalmaz 
DVD-írót). A legtöbb ilyen átalakító támogatott FreeBSD 
alatt is, csatlakoztatás után a rendszermag üzenetei között 
megtaláljuk a létrejött eszköz nevét, amelyet céljának meg- 
felelően tudunk használni. 


umassO: Acer Labs USB 2.0 Storage Device, rev 
552.00/1.09, addr 2 
cdO at umass-simO bus 0 target 0 lun 0 


cdO: cHL-DT-ST DVDRAM GSA-4082B A201: Removable 
55 CD-ROM SCSI-0O device 

cdO: 1.000MB/s transfers 

cdO: cd present [2236704 x 2048 byte records] 


Esetleg nyomtatót is ráköthetünk az USB csatlakozóra, leg- 
feljebb nem tudunk rajta nyomtatni. Ha ulpto lesz az esz- 
köz neve, akkor bizakodhatunk, mert egy kis lépés kell már 
csak a nyomtató felélesztéséhez (amelyet a következő rész- 
ben írok le, mert kis lépés ugyan, de nem rövid a leírása :). 
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ulptOo: hp deskjet 5100, rev 2.00/1.00, addr 2, 
sz-iclass 7/1 
ulptO: using bi-directional mode 


Akár egy USB Bluetooth adapter is szóba jöhet, a nagy ré- 
szük támogatott már FreeBSD alatt is, nem lehet már aka- 
dály a mobiltelefonnal vagy kéziszámítógéppel való kom- 
munikáció sem. 

ubtO: Cambridge Silicon Radio Ltd. Bluetooth USB 
ss dongle, rev 1.10/5.25, addr 2 

Cambridge Silicon Radio Ltd. Bluetooth USB 
ss dongle, rev 1.10/5.25, addr 2 

Interface 0 endpoints: interrupt-0x8l1, 

ss bulk-1n-0x82, bulk-out-0x2 

Interface 1 (alt.config 5) endpoints: 

ss 1s50c€c-1n-0x83, 150c-out—0X3; 

53 wMaxPacketSize—-49; nframes-6, 

sz buffer si7ze-294 


ubtO: 
ubtoO: 


ubtO: 


Mint látjuk a FreeBSD elég jól lekezeli az USB eszközök szé- 
les választékát, bár kevesebb eszközt tudunk majd tényle- 
gesen használni, mint Linux esetén — vásárláskor jobban 
meg kell fontolni az új eszköz megvételét. 


Hálózati eszközök 

Néhány év alatt a legfontosabb kommunikációs felület a he- 
lyi hálózat, illetve ezen át az internet elérése lett. Szinte már 
nem is találni olyan számítástechnikát alkalmazó vállalatot, 
ahol nincs kiépítve helyi hálózat. A FreeBSD egyik fő erős- 
sége a hálózati szolgáltatások nyújtása a helyi hálózat, illet- 
ve az Internet felé, ezért fontos kérdés, hogy milyen eszkö- 
zöket támogat. 

Az Ethernet felülettel rendelkező kártyák szinte teljes típus- 
választéka támogatott, nagyon szerencsétlennek kell ahhoz 
lennünk, hogy a 10/100 kártyák közül pont olyannal rendel- 
kezzünk, amelyet még nem támogat. A legújabb gigabites 
kártyák még tartogathatnak meglepetéseket, de itt is gőz- 
erővel folyik a fejlesztés. 

Korunk slágerével, a WLAN kártyákkal már nem ilyen 
szép a helyzet, ugyanis ezen eszközök támogatási térké- 
pén sok még a fehér folt, bár vannak nagyon érdekes 
kezdeményezések ezen a téren is. Érdemes megnézni 

a 5 http:/www.íreebsd.org címen a kézikönyv Wireless 
Network fejezetét, illetve magyar nyelven ennek tömörebb 
változatát, amely (pillanatnyilag) a 8 http:/www.bsd.hu/ 
dokumentacio/haladoknak/FreeBSD-WLAN/view címen 
érhető el, és nagyon jól összefoglalja azt, amit a témáról 
tudni érdemes. 

lermészetesen otthoni körülmények között a modemet se 
temessük el, bár csak azokat tudjuk használni, amelyek 
úgynevezett hardveres modemek, tehát nem a WinModem 
néven árult olcsó kártyák. Sajnos manapság alig-alig kapni 
olyan modemet, amely soros portként jelenik meg az ope- 
rációs rendszer felé, így sajnos FreeBSD esetén a jelenleg 
kapható modemek nagy része nem fog megszólalni... 

Pár éve a GPRS kapcsolat is - elérhető áron — komoly alter- 
natíva lett, ehhez egyszerűen egy mobiltelefon kell, amely 
képes GPRS szolgáltatásra, és valamilyen módon képesek 
vagyunk a géphez csatlakoztatni. Ez többféle módon is 


lehetséges: kábellel, infrán vagy Bluetooth felületen át. 
Mind a három módszer gyengén támogatott FreeBSD alatt, 
mivel a kábelek eléggé speciális felülettel rendelkeznek, 
ezeket néha Linux alatt is nehéz életre kelteni; az infra kap- 
csolat szinte teljes egészében kimaradt a FreeBSD kernelból,; 
a Bluetooth pedig még új technológia, bár a legtöbb 
Bluetooth lapkát már ismeri a FreeBSD is. Részemről ez 
utóbbi javasolnám a telefonnal való kapcsolat kiépítésére. 
A megnevezett eszközökkel a hálózati kapcsolat kiépítését 
(modemmel, ADSL vagy GPRS útján) a következő részben 
írom le. 


Fájlrendszerek felcsatolása 

A FreeBSD kicsit más módon oldja meg a különféle eszközök 
fájlrendszerbe csatolását, mint azt Linux alatt megszokhattuk. 
A felcsatolásnál a fájlrendszer típusát kétféle módon adhatjuk 
meg, vagy a mount parancs -t paraméterével, vagy közvetle- 
nül a parancs nevében adjuk meg: mount. ext2fs. Az első 
eset tulajdonképpen meghívja azt a parancsot, amit a para- 
méterben kapott név meghatároz, de mégis , szebben" néz ki. 
A felcsatolás lényege — mint említettem — azonos, mégis van 
néhány eleinte sőt akár hosszú távon bosszantó tulajdonsá- 
ga. Példának okáért az egyik ilyen a karakterkészlet meg- 
adásának hiánya, amely akkor jönne jól, ha egy nemzeti 
karakterekkel teli CD/DVD lemezt kellene használni, mivel 
ez mindig a beállított kódlapnak megfelelően jelenik meg, 

a kódlapot átállítva pedig a régi bejegyzések lesznek olvas- 
hatatlanok. Elég rég óta ígérik ennek a problémának a meg- 
oldását, de ezidáig nem került bele az alaprendszerbe. 

A másik fontos hiányosság, hogy a felhasználók nem képe- 
sek a fájlrendszerbe eszközt csatolni, ugyanis erre csak 

a root felhasználó képes. Ez különösen akkor zavaró, ha egy 
munkaállomást többen is használnának, s közülük nem 
mindenki , megbízható" felhasználó (gondoljunk csak egy 
iskolai gépteremre). Ekkor szinte megoldhatatlan a feladat, 
hogy egy egyszerű flopit, CD-lemezt vagy USB tárolóesz- 
közt bármelyik felhasználó használni tudjon. A felcsatolás 
még megoldható, hogy például a mount. ext2fs programra 
root setuid bitet állítunk be, ekkor ugyanis az adott típusú 
fájlrendszert bárki képes lesz felcsatolni. A felhasználók kö- 
rét ACL jogok beállításával tudjuk szűkíteni, viszont a lecsa- 
tolás mindenképpen gondot fog okozni: az összes fájlrend- 
szer típushoz csak egy umount parancs tartozik. Ha ebből 
csinálunk több másolatot, akkor is csak annyit érünk el, 
hogy bizonyos felhasználók képesek a nekik megengedett 
fájlrendszer típusokat felcsatolni és lecsatolni, függetlenül 
attól, hogy ők csatolták-e fel. Ne is kísérletezgessünk a prob- 
léma megoldásán, többnyire észrevétlen biztonsági réseket 
tudunk csak ütni -— az amúgy biztonságos - várfalon. 


A játékok 

Azt kell mondjam, hogy a FreeBSD nem egy játékplatform, 
de annak sem kell aggódnia, aki játszani szeretne. Elsőnek 
rögtön itt van a freebsd-games csomag, amely a tradicioná- 
lis BSD játékgyűjteményt tartalmazza. Ilyen például 

a hangman, amely egy a klasszikus akasztófajáték, természe- 
tesen angol nyelven, és szöveges felületen. Ezek kedves kis 
játékok a régi szép időkből. 

Aki többre vágyik, feltelepítheti a ports adatbázis games 
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a leírását, mivel a többségük egyszerű grafikával, és mini- 
mális kidolgozottsággal rendelkezik, noha a játék maga re- 
mekül el van készítve: a programozóknak nem a grafikák 
és a hangok készítése a kedvenc tevékenység, hanem 

a program megírása. 

Néhány kivételt érdemes megemlíteni, ilyen például 

a FreeCiv, amely FreeBSD alá is feltelepíthető, szépen kidol- 
gozott grafika és hang jellemzi, és egy olyan légkör, amely- 
ből nehéz kimászni, ha belemerültünk. Aztán itt a Ouake 
trilógia (a guakeforge és a guakelZforge a ports-ból telepíthe- 
tő, a Ouakelll esetén a Linux verziót kell telepíteni), ame- 
lyet szintén képesek vagyunk játszani, a két utolsó részéhez 
azonban nem árt a hardveres 3D gyorsítás megléte, külön- 
ben könnyen képregényhez hasonló játékmenet lesz a vég- 
eredmény. 


Az irodai programok 

Alapvetően a FreeBSD nem rendelkezik irodai munká- 

ra alkalmas programcsomaggal, azonban van néhány, 
amelyet telepíteni tudunk. Ezek közül szövegszerkesztés- 
re az AbiWord programot használhatjuk, amely az egy- 
szerűbb munkákra tökéletes. Akinek ez nem elég, telepít- 
heti a KOffice programcsomagot is, amely több olyan ki- 
sebb program együttese, amelyekkel szinte minden ott- 
hon felmerülő munkát meg lehet oldani. lermészetesen 
telepíthető az OpenOffice.org 1.1.3 is, remélem mindenki- 
nek ismerősen cseng a neve. Ez utóbbiból érdemes egy 
előre lefordított bináris csomagot megszerezni, mivel 

a fordításához akár egy nap és 4-5 gigabájt adatterület 
szükséges. 


A multimédia használata 

Zene hallgatása és film megtekintése a multimédia alapja, 

s ezeket nem is kell mellőznünk az életünkből FreeBSD 
rendszert használva. A két használandó program mindenki 
számára ismerős szokott lenni: az XMMS és az MPlayer. 
Egyszerűen csak annyit kell tennünk, hogy feltelepítjük 
ezeket a programokat, a használatuk is teljesen azonos, 
mint azt Linux esetén megszoktuk. 


Auth Gábor (auth.gaborxenaplo.hu) 

Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 


kigyógyulni. 


A FreeBSD projekt honlapja 
2 http://www.freebsd.org 


A magyar FreeBSD honlap 
2 http:/Avww.freebsd.hu 


A magyar BSD honlap 
2 http:/Avww.bsd.hu 


A kézikönyv magyar fordítása 
2 http:/Awww.enaplo.hu/FreeBSD/handbook/ 
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Az OpenOffice.org programozása 


Egy elveszett fejlesztőkörnyezet titkai kedvenc irodai csomagunkban. 


z OpenOffice.org révén a Linux mára egyértelmű- 
AA en eljutott arra a szintre, hogy teljes értékű helyet- 

tesítője lehet egy windowsos irodai munkaállo- 
másnak. Mit is jelent ez? lartalmaz egy szövegszerkesztőt, 
egy táblázatkezelőt, van benne bemutató-készítő, egy rajzo- 
ló-program, sőt mi több, egy remekbe szabott képletszer- 
kesztőt is találunk a csomagban. Mindezt egy ízléses fel- 
használói felületen, és nem utolsó sorban széles fájlformá- 
tum támogatással. 
Mindenünk megvan? Mint tudjuk, az MS Office tartalmaz 
egy önálló adatbázis kezelőt, Access néven, itt mintha ez hi- 
ányozna. Ám a súgó rövid tanulmányozása után azonnal 
kitűnik, hogy nem erről van szó. Az Eszközök menü Adat- 
források... menüpontja alatt beállíthatjuk, hogy mely 
Adabas, MySOL, dBase, tetszőleges ODBC, vagy JDBC 
adatforrást szeretnénk használni. lermészetesen a sima 
szöveges állomány, illetve a munkafüzet is használható. 
Mintha még mindig nem lenne teljes a kép. Gondolkoz- 
zunk csak egy picit. Hát persze, a makrók, és az ezekkel já- 
ró vírusok. Ez az, aminek a hiánya eddig álmatlan éjszaká- 
kat okozott mindannyiunknak, hát végre Linux alatt is elér- 
hetőek! Na jó. Hosszú és parttalan vitát indítana el, ha azt 
kezdeném el boncolgatni, hogy mi értelme egy közel teljes 
értékű fejlesztőkörnyezetet építeni egy szövegszerkesztőbe. 
Inkább nézzük meg, mi mit nyerhetünk abból, ha tudjuk 
ezt használni. 
Essünk neki! Nyissunk meg egy új szöveges dokumentu- 
mot bármely OpenOffice.org alkalmazásból a Fájl/Új/ 
Szöveges dokumentum menüponttal. Azonnal mentsük is el 
egy beszédes nevű állományba a Fájl/Mentés másként... 
menüpont segítségével. Legyen mondjuk ez az 
ElsoMakrom.sxw. Ezután válasszuk ki az Eszközök/Makrók/ 
Makró... menüpontot és időzzünk el egy pillanatra. 
A most látható ablakban találjuk az elérhető makrók listáját, 
gyűjtőkbe szervezve. A bal oldali fa struktúra tartalmazza 
az előbb említett gyűjtőket, azaz azokat a helyeket, ahol Ba- 
sic nyelven írt makrókat találhatunk. Nem említettem vol- 
na? Az OpenOffice.org-ban is egyfajta objektum-orientált 
Basic nyelven dolgozhatunk, akárcsak a másik irodai cso- 
magban. Visszatérve a gyűjtőkre, egy soffice nevűt minden- 
képp látni fogunk, az ebben található modulok makróit bár- 
mely dokumentum elérheti. Ezen kívül minden megnyitott 
dokumentum egy további gyűjtőt képez. 
Dolgozzunk tehát a saját állományunkba. Válasszuk ki 
a Makró forrásaként az ElsoMakrom.sxw gyűjtő alatti Stan- 
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C Karakterként 
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dard könyvtárat, és kattintsunk az Új gombra. Ekkor az 
OpenOffice.org megkér, hogy határozzuk meg a modul 
nevét. Fogadjuk el nyugodt szívvel a Module1 nevet, és 
kattintsunk az Ok gombra. Ekkor elindul a Basic IDE 
(Integrated Development Environment - Integrált Fejlesztői 
Környezet) , melyben két üres eljárás togad minket. 

Mielőtt továbblépnénk, vessünk még egy pillantást a mak- 
rók szervezése mögötti elképzelésre. A gyűjtő egy logikai 
szervező egység, amely egy-egy dokumentumot jelképez, 
vagy adott esetben maga az soffice, amely bárki számára 
elérhető. A gyűjtők alatt található könyvtárak olyan egysé- 
gek, melyek moduloknak adhatnak helyet. A modulok je- 
lentik a legkisebb egységet. Egy modul egy forrásállományt 
jelent, amely természetszerűleg eljárásokból épül fel. Utób- 
bi eljárások a makrók. 

Ezek szerint az előbb látott két üres eljárás, a Main és 

a Macrol1 egyből két új makrót jelent? A válasz igen. 
Zárjuk be a Basic IDE-t és keressük meg újra a Makró... 
menüpontot. Kiválasztva a dokumentumunk Standard 
könyvtárának Module1 modulját, látható, hogy az előbb 


még üres jobb oldal már két makrót tartalmaz. Válasszuk 
ki bármelyiket és kattintsunk a Szerkesztés gombon. Így 
ismételten a fejlesztőkörnyezetben találjuk magunkat. 

A fejlesztőkörnyezet színkiemeléssel segíti a munkát, és 
hely érzékeny súgó is van, amit az F! billentyűvel csalogat- 
hatunk elő. Sajnos ez utóbbi angol nyelvű, viszont annál 
bőségesebb. Lássunk végre egy példát egy valódi makróra! 
Először is töröljük a Macrol eljárást, majd a Main rutint az 
alábbiaknak megfelelően írjuk meg: 


Sub Main 


kepURL -— 
5 beszúrása" , 
if kepURL — "7 
s nyomott 

exit sub 
endif 


InputBox ("Kép URL címe:7", "kép 
-file:///") 


then " a felhasznalo Megse-t 


dokumentum - ThisComponent 
szoveg - dokumentum.getText 0O 


grafika - dokumentum. createlnstance 
sz ("com.sun.SsStar.text.Graphicobject") 
grafika.GraphicURL - kepURL 


lathatokurzor - dokumentum.getCcurrentController 
sz () .getviewcursor () 

szovegKurzor - szoveg.createTextCursorByRange 
sz (lathatokurzor.getStart 0) 


szoveg. insertTextContent (szovegkurzor.getStart 
—m(), grafika, false) 


End Sub 


Ennek az egyszerű makrónak az a feladata, hogy egy képet 
szúrjon be arra a helyre, ahol a kurzor áll. Megjelenít egy 
beviteli ablakot, ahol a kép URL-je határozható meg. Az Ok 
gombra kattintva a kép beszúrásra kerül. Ennél azonban 
felhasználóbarátabb megoldást is alkalmazhatunk. Készít- 
sünk egy igazi tündért, és helyettesítsük ezzel a Beszúrás 
menü Kép pontját. 

Ehhez már egy önálló párbeszédablakra lesz szükségünk. 
A Basic IDE-ben alul láthatjuk azt a fület, amely jelzi, hogy 
épp a Module1 modult szerkesztjük. Kattintsunk ezen a fü- 
lön jobb egérgombbal és válasszuk az előugró helyi menü- 
ből a Beszúrás/BASIC-párbeszédablak pontot. A párbeszéd- 
ablak szerkesztőjét látjuk, egyelőre egy üres ablakkal. Ettől 
kezdve az alul található fülekkel ugrálhatunk a forráskód és 
az ablak szerkesztője között. 

Vezérlők elhelyezéséhez meg kell nyitnunk a Vezérlőelemek 
ablakot. Ezt a felül található eszköztárak azon ikonján törté- 
nő kattintással csalogathatjuk elő, melyen egy jelölőnégy- 
zet, egy választógomb, valamint egy gördítősáv egyszerre 
látható. Innen kedvünkre válogathatunk a vezérlők között 
az olyan egyszerűektől, mint a nyomógomb, egészen az 
olyan összetettekig, mint a fájlkiválasztás. 

Rakjunk is fel egy fájlkiválasztó elemet az ablakra. Az elem 
felhelyezése, átméretezése és mozgatása magától értetődő, 
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játszunk is el vele egy picit. Ha már elégedettek vagyunk 

a munkánkkal, helyezzünk el négy új gombot is. Bármely ele- 
men a jobb egérgombbal előhívhatjuk a helyi menüt. Itt a T4- 
lajdonságok... menüpont kiválasztásával, vagy az elemen ket- 
tős kattintással megnyithatjuk az elem lulajdonságok lapját. 
A gomboknak adhatunk saját nevet, melyre a makrókból 
hivatkozhatunk, illetve egy szövegcímkét. Első gombunkat 
nevezzük el Elozo-nek, címkéje legyen , c c Előző". A kö- 
vetkező neve legyen Kovetkezo, címkéje pedig , Következő 
557. A továbbiaknak legyen Befejezes neve, Befejezés 
címkéje, illetve Megsem neve, Mégsem címkéje. Az Elozo 
gomb Engedélyezett mezőjét pedig állítsuk Nem értékre. 

A felhasználóbarátság jegyében adjunk hozzá az ablakhoz 
még egy egyszerű címkét, és írjuk bele a , Válaszd ki a ké- 
pet!" szöveget. A teljes ablaknak is előhívható a Iulajdonsá- 
gok lapja, így lehet neki címet adni. Végezetül a Vezérlők 
eszköztár utolsó ikonjára kattintva bekapcsolhatjuk 

a Tesztüzemmódot, ezáltal kipróbálhatjuk, hogyan is fog 
kinézni az ablak, amikor élesben használjuk. 

A Tesztüzemmódot az ESCAPE billentyűvel hagyhatjuk el. 
Ahhoz, hogy gombjaink értelmes életet éljenek, eljárásokat 
kell hozzájuk írnunk, majd ezeket az eljárásokat össze kell 
kötni a gombok megfelelő eseményeivel. Váltsunk tehát 
vissza a kódszerkesztőre és programozzunk egy kicsit. 

A párbeszédablakunk referenciáját modulszinten határoz- 
zuk meg, ez már majdnem olyan, mint egy globális változó. 
A megvalósítás azonban így jelentősen egyszerűsödik. 


Private parbeszedAblak as Variant 

Sub Main 
parbeszedaáAblak -— createunoDialog 
sz (DialogLibraries.Standard.Dialogi1) 
parbeszedAblak.execute () 

End Sub 

Sub ParbeszedAáAblakMegsem 
parbeszedAblak.endExecute () 

End Sub 

Sub ParbeszedAblakBefejezes 
Dim kepURL as String 
parbeszedAblak.endExecute () 


Eleresi utat fogunk kapni, ezt at kell 
sz alakitani 

kepURL —- ConvertTOURL 

ss (parbeszedáAblak.Model . Fi lecontrol1.Text) 


dokumentum - ThisComponent 
szoveg - dokumentum.getText 0O 


grafika - dokumentum. createlnstance 
sz ("com.sun.Star.text.Graphicobject") 
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grafika.GraphicURL - kepURL 


lathatokurzor - dokumentum.getcCurrentController 
sz () .getviewcursor 

szovegKkurzor - szoveg.createTextCursorByRange 
sz (lathatokurzor.getStart 0) 


szoveg. insertTextContent (szovegkurzor.getStart 
3 (), grafika, false) 


End Sub 


A régi Main eljárás ParbeszedAblakBefejezes nevet kapott, 
és ennek megfelelően módosult. Az új Main létrehoz egy pél- 
dányt az ablakból és elindítja. A ParbeszedAb lakMegsem mind- 
össze bezárja az ablakot. A két új eljárást a megfelelő gombok- 
ra történő kattintás eseményéhez kell rendelni. Ehhez vált- 
sunk vissza a párbeszédablak szerkesztőre és a gombok Tulaj- 
donságok lapjának második fülén az Inicializáláskor mezőt 
töltsük ki. Ehhez nincs szükség gépelésre, a mellette található 
gombbal tallózhatunk a makrók, azaz az eljárások között. 

A közel kész modul Main makróját elindítva előugrik az ab- 
lak, és már képet is tudunk beszúrni. Viszont nem tündér 

a tündér, ha nincs több oldal, amin a Következő gomb folya- 
matos nyomkodásával nem lehet ugrálni, így hát még 
dolgoznunk kell egy kicsit. Ne szaladjunk azonban előre, 
hiszen már most is használható makróval van dolgunk. 
legyük még kényelmesebbé a használatát azzal, hogy kite- 
szünk az eszköztárra egy gombot, amivel azonnal indítható. 
Egyszerűen kattintsunk az eszköztáron jobb gombbal, és 
válasszuk a Testreszabás... pontot. Bal oldalon görgessünk 
az ElsoMakrom.sxw BASIC makrók elemig és bontsuk ki. 
Keressük meg a Standard könyvtár Module1 moduljának 
Main makróját. Ezután keressük meg a jobb oldalon azt 

a pontot, ami alá szeretnénk beszúrni az új gombot. Ezután 
kattintsunk a Hozzáadás —: gombra. Jópofa ikonokhoz 
kattintsunk az Ikonok... gombon. Ellenőrizzük, hogy az új 
gomb melletti jelölőnégyzet be van-e jelölve. Ha minden 
rendben, kattintsunk az Ok-ra, és élvezzük az egykattin- 
tásos makróindítás hihetetlen élményét. 

Térjünk vissza tündérünkhöz és adjunk értelmet az Elozo 
és Kovetkezo gomboknak. Mint tudjuk, a beszúrt képet el- 
helyezhetjük egy, a bekezdéshez kötött horgonyhoz képest, 
illetve beszúrhatjuk úgy is, mintha egy karakter volna. Bíz- 
zuk ezt a döntést is a felhasználóra azáltal, hogy a tündér 
következő oldalán két választógombbal szembesítjük. Az 
egyikkel bekezdéshez horgonyozhatja a beszúrandó képet, 
a másikkal karakterként végezheti el a beszúrást. 

Ehhez már oldalakra lesz szükségünk. A párbeszédablak 
szerkesztőben, ha bármely vezérlő Iulajdonságok lapját 
megnézzük, láthatjuk, hogy van egy Oldal (fázis) tulajdon- 
sága. Ez jelenleg az összes elemre 0. Ez azt jelenti, hogy az 
összes oldalon elérhető az adott elem. Amennyiben ez az 
érték 1, akkor csak az 1. oldalon, ha 2, akkor csak a 2-on, 
stb. látható. A léptetés megvalósításához gombjaink ezen 
tulajdonságát 0-án hagyjuk, hogy mindig látszódjanak, 

a már meglévő címkét és fájlválasztót 1-re állítjuk, és felve- 
szünk a 2. oldalra néhány vezérlőt. 

Először is tehát állítsuk 1-re a címke és a fájlkiválasztó Oldal 
(fázis) tulajdonságát. Úgy tűnik, ettől még nem változott 
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semmi. Most állítsuk át az egész ablak Oldal (fázis) tulaj- 
donságát 2-re. Az előbb említett vezérlők eltűnnek, mintha 
sosem lettek volna ott. Ezután tegyünk fel egy címkét és 
két választógombot. A választógombok nevei legyenek 
Bekezdeshez és Karakterkent. A Bekezdeshez választó- 
gomb Tulajdonságok lapján az Állapot mezőt állítsuk ar- 
ra, hogy Kfjelölve. 

Az előbb elkészített vezérlők Oldal (fázis) tulajdonsá- 
ga önműködően 2 lett. Ez nekünk jó is, viszont az ab- 
lak oldal tulajdonságát vissza kell állítanunk 1-re, hi- 
szen azt szeretnénk, hogy az ablak létrehozásakor ez 
legyen az, amit a felhasználó meglát. Most újra neki 
kell esnünk a kódolásnak, ez viszont már nem lesz 
nehéz. Szükség van az Elozo és kovetkezo gombok 
eljárásaira, és ki kell egészítenünk 

a ParbeszedAblakBefejezes rutint a horgony kezelésé- 
hez. Lássuk tehát a teljes kódot: 


Private parbeszedAblak as Variant 

Sub Main 
parbeszedAblak - createunoDialog 
sz (DialogLibraries.Standard.Dialogi1) 
parbeszedAblak.execute () 

End Sub 

Sub ParbeszedAblakElozo 
parbeszedAblak.Model.Step — 1 
parbeszedAblak.Model.Elozo.Enabled - false 
parbeszedAblak.Model . Kovetkezo.Enabled — true 

End Sub 

Sub ParbeszedAblakKkovetkezo 
parbeszedAblak.Model.Step — 2 
parbeszedAblak.Model.Elozo.Enabled -— true 
parbeszedAblak.Model . Kovetkezo. Enabled — false 

End Sub 

Sub ParbeszedaáblakMegsem 
parbeszedAblak. endExecute () 

End Sub 

sub ParbeszedaáablakBefejezes 
Dim kepURL as String, horgony as Long 
parbeszedAblak. endExecute () 


Eleresi utat fogunk kapni, ezt at kell 
sz alakitani 

kepURL - ConvertTOURL 

s (parbeszedáAblak.Model . Fi lecontrol1.Text) 








" Ha Allapot - kijelolve, akkor State - 1 lermészetesen az Elozo és Kovetkezo gombokhoz megfelelő g 
eljárásokat még a gombok eseménykezelőinek meg kell adni, 2 
if parbeszedAblak.Model .Karakterkent.State — 1 de ezt a harci feladatot már az Olvasóra bízom. Sikerült tehát (0 
then közösen létrehoznunk egy tündért, amely egy képet szúr be s 
horgony - com.Ssun.Star.text. a dokumentumba, és még a horgonyt is meg tudjuk adni D 
5 TextcontentAnchorType.AS CHARACTER a segítségével. Készítettünk hozzá gyorsindítót is az eszköz- 0) 
elseif parbeszedAblak.Model . Bekezdeshez.State - 1  tárra, így ezt a szenzációs makrót, mely a már beépített funk- pen 
5 then cióként elérhető képbeszúrást végzi el hibátlanul, hihetetle- aT 
horgony - com.Sun.Sstar.text. nül gyorsan érhetjük el. Erdemes megismerni olyan eszközö- e 
5 TextContentAnchorType . AT. PARAGRAPH ket is, melyekről elképzelhető, hogy nem sűrűn fogjuk ss 
endif előnyben részesíteni őket más megoldásokkal szemben. ; 
Azért el kell ismernünk, igen gyorsan össze lehetett dobni s 
dokumentum - ThisCcomponent ezt a kis tündért, és a szükséges fejlesztőkörnyezet már tele- — . 
szoveg - dokumentum.getText O pítve volt a gépre egy irodai csomag formájában. Nem ebben - 
a környezetben fogjuk megírni a világegyenletet megoldó AZ 
grafika - dokumentum.createlnstance programot, de kisebb feladatokra, különösen a táblázatkeze- ő 
sz ("com.SsSun.Star.text.Graphicobject") lés területén, használható eszközre találhatunk a Basicben. o 
grafika.GraphicURL - kepURL A http://api.openoffice.org/ DevelopersGuide/ 
grafika.AnchorTrype - horgony DevelopersGuide.html címről elérhető több, mint 1000 olda- 


las leírás bőséges ismertetővel szolgál a témával kapcsolat- 
lathatokurzor - dokumentum.getCurrentcontroller ban. A fenti példa is innen származik. Akit érdekelnek az 


50 .getviewcursor O OpenOffice.org programozóknak nyújtott szolgáltatásai, 
szovegkurzor - szoveg.createTextCursorByRange mindenképpen töltse le a leírást. Akár Java nyelven is 
5 (lathatokurzor.getStart 0) készíthetők ugyanis olyan alkalmazások, melyek az 


OpenOffice.org lehetőségeit aknázzák ki. Érdemes egy-két 
szoveg. insertTextContent (szovegkurzor.getStart pillantást vetni erre is. 
—3(), grafika, false) Sok örömet a programozáshoz! 


End Sub Fülöp Balázs 
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PHP5 - Uj generáció (3. rész) 


.. . Avagy hogyan használjuk okosan az osztályokat és objektumokat PHP5-ben. 


z előző részben az objektumszemléletű fejlesz- 
AA tés igazi erősségét adó örökléssel, mint nagy 

témakörrel foglalkoztunk. Szó volt az ezekkel 
szorosan kapcsolatban álló elvont (abstract) osztályokról 
illetve felületekről (interface) és a bennük rejlő lehetősé- 
gekról, végezetül pedig megnéztünk néhány mágikus 
tagfüggvényt a teljesség igénye nélkül. 
Most megnézzük, mire jók azok a bizonyos kivéte- 
lek, miként másolhatjuk az objektumainkat értékeik 
szerint, illetve hogyan írhatunk elő objektumtípuso- 
kat paraméter gyanánt. Ne is húzzuk az időt, kezd- 
jünk bele! 





Kivételkezelés 

PHP 5-ben is bevezették a Java, Cs nyelvekből már jól 
ismert kivételeket. Ezek olyan felhasználói , hibaüzene- 
tek", amelyeket a programkódban használhatjuk hibajel- 
zések, különleges események kezelésére. Működésének 
lényege, hogy bizonyos feltétel teljesülése esetén mond- 
juk egy objektumból kivételt dobunk, amelyet azonban 
az objektum metódusát hívó programkód fog majd el- 
kapni, lekezelni. Ez így homályos lehet, ezért nézzünk 
egy példát: 


ca?php 
class Negyzet í 
private $oldal — 0; 


public function , construct($oldal) ( 
$this-soldalHossztBeallit($oldal); 


public function oldalHossztBeal lit($ertek) ( 
if Cis numeric($ertek)) ( 
$this-soldal-$ertek; 
j else ( 
throw new Exception("Értékadási hiba: 
a megadott érték nem szám"); 


public function teruleteO) ( 
echo $this-soldal"$this-soldal; 
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$negyzet1-new Negyzet (0); 

try i 
$negyzet1-soldalHossztBeal lit("asd"); 
$negyzet1-:teruleteO ; 

l catch (Exception $ex) ( 
echo $ex-sgetMessage(l) ; 

J 


75 


A kulcs az oldalHossztBeallit( metódusban van. Jelen 
esetben, ha olyan értéket adunk meg, ami nem szám, akkor 
szeretnénk, ha erről értesítene bennünket az objektum, 
hogy a felhasználás pillanatában tudjuk, mi a hiba. A fő- 
programban a try blokk szolgál arra, hogy megpróbáljuk 
beállítani az oldalhosszt. Ez természetesen nem biztos, 
hogy sikerülni fog. A catch blokkban kezeljük le azt, ha 
esetleg a try blokk valamelyik parancsa nem sikerült, s az 
adott típusú kivétel keletkezett. Jelen esetben megpróbá- 
lunk karaktersorozatot adni értékül az oldalnak, ami nem 
fog sikerülni. Ekkor a try blokkban az utasítások végrehaj- 
tása megszakad, a futás átugrik a megfelelő catch blokkba 
(ahol az adott típusú kivételre várunk), és végrehajtja az ott 
található összes utasítást. 

Egy try blokkot tetszőleges számú catch blokk követ. Mint 
már említettem is, abba a blokkba kerül a vezérlés a hiba 
esetén, amilyen típusú az objektum által dobott kivétel 
(jelenleg Exception típusú). Ez akkor lehet igazán hasznos, 
ha mi magunk is saját kivételtípusokat készítünk, és más 
más típusra máshogyan szeretnénk reagálni. 
lermészetesen egy blokkon belül több azonos kivételt elő- 
idéző utasítás is lehet (az oldalhossz beállítása mellé vala- 
mi), azonban minden esetben csak egyetlen kivétel jön 
létre, hiszen utána azonnal a catch blokkban találjuk 
magunkat. 

A módszer előnye az, hogy if-ek nélkül egyszerűen kezel- 
hetjük a hibákat, ráadásul a használt objektum belső szer- 
kezetének ismerete nélkül. legyük fel, hogy a négyzetnek 
beállítjuk még a színét is. Ha nem megfelelő színt adunk, 
akkor ott is kiírathatunk egy hibaüzenetet, s ilyenekből tet- 
szőleges számú lehet. Ekkor azonban a felhasználás során 
alkalmazott try-catch szerkezet a világon semmit sem vál- 
tozik, csak végzi az egyszerű hibakezelési feladatot. 
lermészetesen nem szükséges minden esetben lekezelni 

a kivételt... nem kell tehát try blokkba foglalni. Ilyenkor, ha 
mégis bekövetkezik, végzetes hibával leáll a program futá- 


sa, ezért célszerű mindig alkalmazni. Olyan eseteben hagy- 
hatjuk el mégis, mint a fenti példa. Ha ugyanis a program- 
ból mindig ugyanazt a konstans számértéket állítjuk be, so- 
hasem fog kivétel képződni. A dolog csak akkor érdekes, ha 
mondjuk a felhasználó által beolvasott értéket szeretnénk 
megadni oldalhosszként, amelyet nem ismerhetünk előre. 


Tipuselőírás, típusmeghatározás 

A fentiekben már volt szó a catch blokkok kapcsán arról, 
hogy a kivétel, mint osztály típusával azonosítható egy ilyen 
kódrészlet. Az előző változatokhoz képest szokatlan a (típus 
változónév) formula, amely itt arra hivatott, hogy meghatá- 
rozza, milyen típusú legyen az adott paraméter. Mivel a PHP 
egy gyengén típusos nyelv, ez az előírás csak azt erőlteti, 
hogy a paraméter objektum legyen, mely a típusként meg- 
adott nevű osztály egyik példánya. Ez az úgynevezett type 
hinting minden függvényre és metódusra alkalmazható. 


function test(Negyzet $negyzet) í( 
$negyzet-steruleteO ; 
ú 


A fenti kódrészlet az előző példa kódját felhasználva szem- 
lélteti az esetet. A test függvény csak a Negyzet osztály pél- 
dányait fogadja paraméterül. Nem lehet más osztály példá- 
nya, egyáltalában csak osztályokat fogad paraméterül, és 
null sem lehet az értéke. 

A fenti lehetőséget minden olyan esetben haszonnal alkal- 
mazhatjuk, ahol előre meghatározott objektumpéldányo- 
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kon kell műveletet végeznünk (így garantált, hogy létezik 
a paraméter megadott metódusa, stb.). 


Objektumok másolása 

Szó volt róla, hogy a PHP 5 egyik legjelentősebb változtatá- 
sa, hogy az objektumok átadása a régi érték szerinti megol- 
dás helyett már cím szerinti. Ez azt jelenti, hogy $a-$b ese- 
tén mindkét változó ugyanarra a memóriaterületre fog mu- 
tatni (természetesen csak objektumok esetén), ezért ha az 
egyiknek bármilyen tulajdonsága megváltozik, valójában 

a másik is meg fog változni. Olyan ez, mintha két póráz 
lenne a kezünkben, amely ugyanazon kutyában végződik. 
Gyakran előfordulhat az a dolog, hogy mi valóban szeret- 
nénk megduplázni úgy azt az objektumot, hogy valóban 
kettő legyen belőle, mert mindkettőn egymástól független 
műveleteket szeretnénk végezni, tehát kell nekünk két pó- 
ráz, amely két különböző kutyában végződik. Még mindig 
a fenti négyzetes példánál maradva 


$negyzeti - new Negyzet (5); 
$negyzet2 - clone $negyzeti1; 
$negyzet2-soldalHossztBeal lit(3) ; 


$negyzet1-:teruleteO ; 
$negyzet2-:steruleteO ; 


A fenti kódrészlet a futás után kiír egyszer 25-öt, majd 9-et, 
jól látszik tehát, hogy a két példány különböző. Ez olyan 
esetekben lehet hasznos, ahol van egy sok-sok tulajdonsá- 
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got tartalmazó objektumunk, be is vannak állítva ezek az 
adatok jól, és mi szeretnénk valamiért a rajta végzett műve- 
letet ,elágaztatni", és az új objektumban csak bizonyos érté- 
keket megváltoztatni. 

Felvetődik itt azonban egy probléma, amelyet legjobb lesz, 
ha egy példán keresztül próbálok meg bemutatni: 


c?php 


class Ember ( 
private $nev; 
private $szuletesiEv; 


public function . construct($nev, $szuletesiEv) ( 
$this-ssetNev($nev) ; 
$this-ssetSzuletesiEv($szuletestiEv) ; 


public function setszuletesiEv($szuletesiEv) ( 
$this-sszuletesiEv-$szuletesiEv; 


public function setNev($nev) ( 
$this-5nev-$nev; 


public function getNevO) 1 
return $this-snev; 


public function getSzuletesiEvŐ) í 
return $this-sszuletestiEv; 


class Anya extends Ember ( 
private $gyermeke; 


public function setGyermeke(Ember $ember) ( 
$this-sgyermeke-$ember ; 


public function getGyermekeO) í 
return $this-sgyermeke; 


$ellie - new Anya( "Ellie" , 1920) ; 
$jockey - new Ember( "Jockey" , 1950); 
$ellie-ssetGyermeke($jockey) ; 


$mary - clone $ellie; 

$mary-ssetNev( "Mary" ) ; 

$el]1e-sgetGyermeke() -ssetSzuletesiEv(1945); 
echo $mary-:getGyermeke0 -sgetszuletesiEvŐ ; 
7: 


A fenti kódrészlet az alábbi szituációt takarja: vannak Embe- 
rek, és vannak olyan speciális emberek, akik egyben Anyák, 
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s van gyerekük, aki egy másik Ember. A példában létrehoz- 
tuk El 1ie-t, és Jockey-t, mint embereket, majd azt mond- 
tuk, hogy Ellie mama Jockey bácsi anyukája. Ez eddig 
rendben is volna. 

Ezek után lemásoltuk El lie anyukát Mary néven, majd 
Ellie fiának születési évét átállítottuk. Sajnálattal tapasztal- 
tuk azonban az eredményt, hogy Mary fiának születési éve 
is megváltozott, amiből hajlamosak vagyunk arra következ- 
tetni, hogy a gyermekeik azonosak, pedig mi nem ezt sze- 
rettük volna. 

A jelenség magyarázata az alábbi: az anyák gyermekük- 

re referenciaként hivatkoznak, hisz látszik a kódból 
(setGyermekeO ), hogy egyszerű egyenlőség operátorral 
,másoltuk" őket. Ez nem baj, ez az eredeti szándékunk, 
hisz így szép és helyes a megoldás. A baj abból adódik, 
hogy a clone hívás alapértelmezetten ún. sekély másolatot 
(shallow copy) készít, mindent egy az egyben átmásol az új 
objektumba, tehát referenciát is referenciába másol, így 

a két objektum $gyermeke tulajdonsága ugyanarra a pél- 
dányra mutat. A kutyáknál maradva: hiába van nekünk 
két külön kutyánk a póráz végén, ha hozzájuk van kötözve 
egy harmadik közös kutya. 

Nem mindig hasznos tehát, ha egy objektum egy az 
egyben másolódik (néha működésből adódóan sem 
célszerű — például nincs mindenre szükségünk). Erre 
megoldás lehet az, ha egy osztályban rögzítjük előre, 
hogy egy esetleges másolás esetén milyen értékek ho- 
gyan menjenek át a másolatba. Erre szolgála  cloneO 
nevű mágikus tagfüggvény, amely a clone utasítás ki- 
adásakor hívódik meg az adott objektumra. Bármilyen 
utasítás, amit itt rögzítünk, végrehajtódik. A fenti példa 
javítása tehát: adjuk hozzá az Anya osztályhoz az alábbi 
metódust: 


public function . clone() ( 
$this-sgyermeke - clone($this-sgyermeke) ; 


A hivatkozott referenciára is készítünk valódi másola- 
tot. Fontos megjegyezni, hogy nem kell minden attribú- 
tumot átmásolnunk, azoka  cloneO metódustól füg- 
getlenül automatikusan átmásolódnak, nekünk csak 
felül kell írnunk a nem kívánt értékeket. 

lovábbi érdekesség, hogy ha megengedjük 

a setGyermeke) metódusban, hogy ne csak Ember, 
hanem Anya is lehessen gyerek (minek tulajdonsága 
referenciát tartalmaz), a fenti másolóalgoritmus ak- 
kor is hibátlanul működik, hisza  clone() metódus- 
ban kiadott clone utasítás hatására a gyermekre (aki 
anya is lehet) szintén meghívódik annak  cilone() 
metódusa, és ez így gyűrűzik egészen addig, amíg 
van hivatkozásunk a hivatkozott objektumban. 

Már csak egy nagy témakör maradt hátra, neveze- 
tesen a PHP 5 új Reflection API-ja, amely az osztá- 
lyok, objektumok igen széles körű és részletes 
elemzésére szolgál — akár futásidőben is. A sorozat 
következő részében ezen a területen teszünk egy 
kisebb kirándulást. 





Komáromi Zoltán 


Számítógép hálózatok (14. rész) 


Virtuális áramkörök és datagram alapú alhálózatok működése, forgalomirányítás 


a hálózati rétegben. 


Bevezetés 

Az előző részben már elkezdtünk foglalkozni a hálózati 
réteggel, amelynek segítsége nélkül a hosztok képtelenek 
lennének megtalálni egymást a hálózaton. Arról is volt szó, 
hogy alapvetően kétféle elképzelés létezik arról, milyen szol- 
gálatokkal is rendelkezzen a hálózati rétegnek. Az első elgon- 
dolás szerint a hálózati rétegnek összeköttetés alapú szolgá- 
latot kell megvalósítani, amely nagyon hasonló egy telefonon 
történő kommunikációhoz. Valamelyik gép felhívja a mási- 
kat, kiépül a kapcsolat, majd megtörténik az adatcsere. Ami- 
kor mindkét gép befejezte a társalgást, a kapcsolatot lebont- 
ják. Ilyen elv szerint működnek például az ATM hálózatok. 
Az Internet és protokolljai azonban egy másik szemléletet 
követnek: itt a szolgálat mindig összeköttetés nélküli. 

Az ilyen típusú kommunikációt úgy képzelhetjük el, mintha 
levelezve, postai úton kommunikálnánk valakivel. Az elkül- 
dendő adatot , becsomagoljuk" egy úgynevezett datagramba, 
ráírjuk a címzettet és a feladót, majd útjára engedjük. 
Amikor a hálózati réteg megvalósításáról beszélünk, akkor 
tulajdonképpen a kommunikációs alhálózat (vagy röviden 
alhálózat) működését vesszük szemügyre. Emlékezzünk 
vissza: az alhálózat az a hálózat, amely a gépeket, illetve he- 
lyi hálózatokat egymással összeköti. Ez a hálózat többnyire 
útvonalválasztókból (routerekból) áll (1. ábra). 


Osszeköttetés alapú hálózat 

Az ilyen jellegű kommunikáció pontosan úgy működik, mint 
amikor telefonon beszélgetünk valakivel. Sőt, tulajdonképpen 
maga a telefonhálózat is összeköttetés alapú hálózat. Amikor 
két gép adatot kíván cserélni egymással, először létre kell 
hozniuk egy kapcsolatot. Amíg ez a kapcsolat él, addig tud- 
nak egymásnak csomagokat küldözgetni. Az ilyen hálózatok 
megbízhatóak, tehát a csomagok nem vesznek el útközben, 
nem sérülnek meg és sorrendhelyesen érkeznek meg. 

A gépek között kiépülő kapcsolatot virtuális áramkörnek 
(virtual circuit) nevezzük. Mivel általában több olyan 
alhálózati útvonal is létezik, amelyen keresztül eljuthatunk 
az egyik géptől a másikig, ezért a virtuális áramkörnek nem 
csak a két gépet kell meghatároznia, hanem egy hozzájuk 
tartozó útvonalat is. Ez az útvonal az összeköttetés felépíté- 
sekor kerül kiválasztásra, tehát minden elküldött csomag 
ugyanazon az útvonalon fog haladni. 

Ehhez azonban a routereknek tudniuk kell, hogy a rajtuk 
átmenő csomagokat melyik kimenetükön keresztül küldjék 
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tovább. Így minden útválasztó rendelkezik egy táblázattal, 
amely hozzárendeli a rajta , keresztülmenő" virtuális áram- 
köröket a megfelelő kimenettel. Amikor beérkezik egy cso- 
mag, akkor az útválasztó a fejlécből meg tudja állapítani, 
hogy az melyik virtuális áramkörön halad, így táblázata 
segítségével a megfelelő kimenetre képes irányítani. 

A helyzetet az bonyolítja kicsit, hogy a virtuális áramkö- 
röknek nem lehet egy globálisan érvényes azonosítószá- 
mod adni, mivel minden gép maga választja ki azokat. 
Így a virtuális áramkörszámok csak helyi szinten érvénye- 
sek. Ha ez nem így lenne, akkor könnyen előfordulhatna 
az az eset, amikor két virtuális áramkör ugyanazt az azo- 
nosítót kapja, és ráadásul ugyanazon az útválasztón is 
megy keresztül. Ebben a helyzetben a router nem tudná 
eldönteni, hogy a beérkező csomagot melyik kimenetre 

is irányítsa. 

Ha a vonal duplex, akkor időnként bekövetkezhet egy elég 
kellemetlen esemény, ami akkor fordul elő, ha két gép egy 
időben kíván kapcsolatot kiépíteni a másikkal. Ilyenkor 

a kapcsolat felépítésére irányuló kérelem mindkét irányban 
egy időben kezd el haladni az alhálózaton. legyük fel, hogy 
a routerek programja olyan, hogy új virtuális áramkör fel- 
építésekor mindig a legkisebb szabad sorszámot rendelik az 
új kapcsolathoz. Amikor a két kérelem két szomszédos 
routerhez érkezik, akkor mind a ketten ugyanazt az azono- 
sítót fogják kiosztani, tehát két különböző virtuális áram- 
körnek ugyanaz lesz a száma ugyanazon a fizikai vonalon. 
Ez azért baj, mert a routerek nem fogják tudni a beérkező 
csomagokról, hogy ez az egyik összeköttetésben egy előre- 
haladó, vagy a másikon egy visszafelé menő-e. 

Amikor a két gép közötti kommunikáció befejeződik, akkor 
a virtuális áramkör lebontásra kerül. 
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Osszeköttetés nélküli hálózatok 

Míg az összeköttetés alapú hálózatoknál a hálózati réteg fe- 
lel az összeköttetés megvalósításáért, addig az összeköttetés 
nélküli hálózatoknál ez egy felsőbb réteg (a szállítási réteg) 
feladata. Az Internet és annak protokolljai esetében a háló- 
zati rétegre csak a neki átadott csomag célbajuttatása van 
bízva. Ehhez nem kell előzetesen kiépített kapcsolat, nem 
kell törődni a forgalomszabályozással és az sem biztos, 
hogy az átvitel hibátlan lesz. (Míg ezeket a feladatokat az 
összeköttetésen alapuló hálózatoknál az alhálózat végezte, 
addig itt ez a gépek feladata). 

Mivel nincs összeköttetés, ezért az útvonal nincs előre kijelöl- 
ve, hanem minden csomag esetén külön számítódik ki. Ezért 
a csomagoknak tartalmazniuk kell a forrás- és a célállomás cí- 
mét. A csomagok egymástól függetlenül kerülnek továbbítás- 
ra, ezért a fejlécben fel kell tüntetni a csomag sorszámát is, hi- 
szen könnyen megeshet, hogy a célhoz nem az útrabocsátás 
sorrendjében érkeznek be a csomagok. (Mivel valószínűleg 
mindegyik más útvonalon keresztül ért célt). Számolni kell 
azzal a lehetőséggel is, hogy egyes csomagok soha sem érkez- 
nek meg, vagy ami rosszabb, a vevő kétszer is megkapja 
ugyanazt a csomagot. Az összeköttetés mentes hálózatok 
tehát korántsem nevezhetők megbízhatónak. Az egymástól 
függetlenül továbbított adatdarabokat datagramoknak nevez- 
zük. Még egyszer hangsúlyozzuk, hogy a datagramoknak so- 
ha nincs előre kijelölt útvonaluk. Egy ilyen hálózat kezelése 
mindenképpen bonyolultabb és munkaigényesebb feladat, 
viszont ezért cserébe sokkal jobban alkalmazkodik a véletlen- 
szerűen jelentkező forgalomváltozásokra. 

Az útválasztóknak az összeköttetés nélküli hálózatokban is 
szükségük van belső táblázatokra, csak ott most nem a vir- 
tuális áramköröket tartják nyílván (mivel ilyesmiről itt nem 
beszélhetünk), hanem a velük kapcsolatban lévő routerek 
címeit. A router a beérkező csomagot a célcíme alapján irá- 
nyítja a megfelelő kimenetre. (Annak eldöntése, hogy me- 
lyik kimenetre kerüljön a csomag, egyáltalán nem egyszerű. 
Erről később bővebben szólunk majd a forgalomirányítási 
algoritmusok tárgyalásakor). 


A két megoldás összehasonlítása 

Nagyon nehéz kérdés, hogy melyik megoldás jobb a másik- 
nál. Az biztos, hogy általánosan nem mondható el egyikről 
sem, hogy az jobb vagy rosszabb lenne. Sőt, azt sem egysze- 
rű eldönteni, hogy egy konkrét helyzetben melyik alhálózati 
megvalósítás felelne meg leginkább az igényeknek. Most 
megpróbáljuk összeszedni mindkét hálózattípus előnyeit és 
hátrányait, illetve mikor jelenthet az egyik hatékonyabb 
megoldást a másiknál. De az itt leírtakat sem szabad örökér- 
vényű törvénynek felfogni, mivel szélsőséges esetekben le- 
het, pont a másik típus lenne a legjobb választás. 

Rögtön az első dolog, ami különbséget jelenthet a virtuális 
áramkörök és a datagramok között az a csomagok mérete. 
Az első esetben csak a virtuális áramkör azonosítószámát 
kell a csomagoknak szállítaniuk, amely lényegesen kisebb 
méretű mint a forrás- és a célcím. Ha kis csomagokkal dol- 
gozunk, akkor ez a méretbeli eltérés jelentős lehet. Ugyan- 
akkor az is igaz, hogy az összeköttetés alapú alhálózatoknál 
a routereknek nagyobb belső memóriára van szükség, ha- 
csak nem akarjuk drasztikusan lecsökkenteni a virtuális 
áramkörök maximális számát. 
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A hálózat sebességét nézve is kompromisszumokra kell 
kényszerülnünk. Míg a virtuális áramkörök esetében az 
összeköttetés felépítése, illetve lebontása időt vesz igénybe, 
addig a datagram hálózatokban ez a késleltetés nem jelent- 
kezik. Viszont a routernek sokkal tovább tart eldönteniük, 
hogy a csomagot melyik kimenetre továbbítsák. 

Ha az összeköttetés várhatóan fennáll hetekig, hónapokig, 
esetleg évekig, akkor sokkal jobb választás a virtuális áram- 
kör. Ha viszont csak időnként szeretnénk kis adatmennyisé- 
get küldeni, tehát akommunikáció úgymond tranzakció jel- 
legű, akkor a datagram a hatékonyabb megoldás. 

A torlódások elkerülését tekintve az összeköttetés alapú háló- 
zatok némi előnnyel rendelkeznek. A szükséges erőforrásokat 
(értsd: routereket) már előre, a kapcsolat felépítésekor le lehet 
foglalni, így azok mindig rendelkezésre fognak állni, amikor 
csak szükség lesz rájuk. Az is igaz viszont, hogy a datagram 
alapú hálózatok sokkal dinamikusabban tudják kezelni a tor- 
lódásokat. Ha egy router nagyon leterhelt, akkor egy másikon 
keresztül mennek tovább a csomagok. Egy adott csomag út- 
vonala tehát mindig az aktuális terhelési viszonyoktól függ. 

A virtuális áramkörök ugyanakkor nagyon könnyen meg- 
szakadhatnak, nem kell hozzá más, mint hogy egy útvá- 
lasztó akár csak egy másodpercre is üzemképtelenné vál- 
jon. Hiába indul újra egyből, a kapcsolat elveszik, és azt új- 
ra fel kell építeni. A datagram alapú hálózatoknál ez nem 
lehet probléma. Egy router kiesése csak azoknak a gépek- 
nek jár kellemetlenséggel, akiknek a csomagjai éppen a kér- 
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Osszeköttetés megvalósítása datagramokkal, és össze- 
köttetésmentes szolgálat virtuális áramkörökkel 
Fontosnak tartjuk, hogy hangsúlyt helyezzünk a szolgálat 
típusa (összeköttetés alapú, illetve összeköttetés nélküli) és 
az alhálózat típusa (virtuális áramkörös vagy datagramos) 
között. A szolgálat típusa a felső réteg számára határozza 
meg, hogy pontosan mit is várhat el az adott rétegtől. 

Az alhálózat típusa már a megvalósítás kérdéskörébe tarto- 
zik. Bizonyos esetekben szükség lehet egy datagramon ala- 
puló összeköttetéses szolgálatra, vagy egy összeköttetés 
nélküli virtuális áramkörös megoldásra. Az utóbbira a leg- 
jobb példa az, ha valaki egy ATM hálózaton szeretne IP 
protokollt használni. 


Forgalomirányító algoritmusok 

A hálózati réteg megvalósításának legfontosabb kérdése az, 
hogy milyen útvonalon jutassa célba az alhálózaton keresz- 
tül menő csomagokat. A LAN-ok világában egyedül 

a switch-ek végeztek forgalomirányítás-szerű tevékenysé- 
get, de azt is csak a hálózaton lévő forgalom csökkentésére. 
Az adatszórásos hálózatoknál nincs szükség forgalomirá- 
nyításra. Ha azonban a forrás és a cél különböző hálózaton 
van, akkor találni kell egy útvonalat, amelyen a csomag el- 
juthat rendeltetési helyére. Az is fontos, hogy ez az útvonal 
a lehető legoptimálisabb legyen. 

Az útvonalat a forgalomirányító algoritmus határozza meg, 
amely része a hálózati szoftvernek. lalán nem meglepő, 
hogy a forgalomirányító algoritmus forgalomirányítást végez, 
amely nem jelent mást, mint eldönteni, hogy egy beérkező 
csomag melyik kimeneten folytassa útját. A virtuális áramkö- 
rökön alapuló hálózatoknál ezt csak az új kapcsolatok felépü- 


lésénél kell elvégezni. A datagramos 
hálózatoknál minden beérkező cso- 
magnál döntést kell hozni. 

Sokféle forgalomirányítási mód- 
szer létezik, vannak rendkívül jól 
működők és vannak kevésbé haté- 
konyak. Mielőtt ezek működésébe 
részletesen is belemélyednénk, 
foglaljuk össze, milyen elvárásaink 
lehetnek egy ilyen algoritmussal 
szemben. Ezek pedig a követke- 
zők: helyesség, egyszerűség, ro- 
busztusság, stabilitás, optimalitás 
és igazságosság. 

Az nagyon jó dolog, ha az algorit- 
musunk helyesen működik, és nem 
hoz hibás döntéseket. Az sem árt, 
ha egyszerű, nem tartalmaz bonyo- 
lult számításokat, így kevesebb erőforrás szükségeltetik 

a megoldáshoz. Robusztusság alatt azt értjük, hogy az algorit- 
változásokra. Egy hálózat életében ugyanis naponta történ- 
hetnek váratlan fordulatok: áramszünet vagy valami hiba kö- 
vetkeztében egy útválasztó kiesik, majd hirtelen ismét megja- 
vul, stb. Nehéz lenne az élet egy olyan hálózatban, amit min- 
dig újra kéne indítani, ahányszor egy router meghibásodik. 
Az igazságosság és az optimalitás alapvető követelménynek 
tűnhetnek, ám e két cél egymással ellentétes. Nyílván nem 
mindig a legigazságosabb megoldás a legoptimálisabb. 
Elképzelhető, hogy globálisan hatékonyabb eredményt 
érünk el, ha időnként egy-egy gép számára nem a legked- 
vezőbb megoldást nyújtjuk. A 2. ábrán láthatunk egy példát, 
ami konfliktushoz vezet az igazságosság és az optimalitás 
között. legyük fel, hogy a A és A, B és B, C és C" között 
olyan nagy a forgalom, hogy telíti az őket összekötő, az áb- 
rán vízszintes helyzetben lévő vonalakat. Az optimális meg- 
oldás az lenne, hogy minél több gép tudjon egymással Za- 
vartalanul kommunikálni, tehát el kéne zárnunk az X és X 
közötti vonalat. Az X hoszt előtt ülő felhasználó viszont ezt 
nem tartaná igazságos elbánásnak. 

A forgalomirányító algoritmusokat két nagy csoportra oszt- 
hatjuk. Az elsőbe az úgynevezett nem adaptív algoritmusok 
tartoznak. Ezek az egyszerűbb eljárások, amelyek a dönté- 
sek meghozatalánál nem vesznek figyelembe mérési, becs- 
lési eredményeket, sőt még az aktuális forgalmi helyzettel 
sem törődnek. Inkább minden számítást előre, , offline" mó- 
don végeznek el, amelynek eredményeit a routerek a háló- 
zat indításakor kapnak meg. lörténjen tehát bármi, két 
pont között minden csomag ugyanazt az utat fogja bejárni. 
Ez az úgynevezett statikus forgalomirányítás módszere. 

A második csoportba az adaptív algoritmusok tartoznak, 
amelyek felfigyelnek a topológiában, illetve a forgalmi vi- 
szonyokban történő változásokra, és ellentétben az előzőek- 
kel, döntéseiket ezen változások figyelembevételével hoz- 
zák meg. Ezt nevezzük dinamikus forgalomirányításnak. 

Az adatív algoritmusok sok mindenben különbözhetnek 
egymástól. Egyesek mindig csak a szomszédos routerektől 
veszik az információkat, mások az alhálózatban lévő összes 
routerével kapcsolatban állnak. Különbözhetnek még ab- 
ban is, hogy milyen módon próbálják az optimalitást meg- 
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valósítani. Például inkább a cso- 
magkésleltetést kívánja-e csök- 
kenteni, mint hogy a teljes 
alhálózat átbocsátóképességét 

a lehető legnagyobbra állítani. 
(A későbbiekben erre még részle- 
tesen is visszatérünk. Most csak 
azt jegyeznénk meg, hogy e két 
cél egymásnak ellentmond, így 
az algoritmusoknak megint vala- 
mi kompromisszumos megoldást 
kell találnia). 


Az optimalitási elv 

Azt már tudjuk, hogy a forgalom- 
irányító algoritmusoknak töre- 
kedniük kell arra, hogy a hálózat 
optimálisan működjön. De vajon 
mit jelent az, hogy optimális? Erre az úgynevezett optima- 
litási elv ad választ. Ennek a fogalom a bevezetése talán 
jobban megvilágítja a forgalomirányító algoritmusok mű- 
ködését. Most még nem foglalkozunk az olyan gyakorlati 
jellegű dolgokkal, mint például a hálózaton jelenlévő for- 
galom, vagy az alhálózat topológiája. 

Az optimalitási elv a következő vallja: ha a B jelű router az 
A és a C router közötti optimális útvonalon helyezkedik el, 
akkor a B-től C-ig vezető optimális útvonal is része annak. 
(Ez egy nagyon egyszerűen bizonyítható tétel, ugyanis indi- 
rekt módon feltehetjük, hogy létezik egy jobb útvonal B és 
C között. Ekkor ezt összekapcsolhatjuk az A-ból B-be vezető 
útvonallal, így egy jobb A-C utat kapunk. Ez azonban ellent- 
mondás, ugyanis az AC út az optimális). Ennek a tételnek 
egy érdekes következménye az, hogy az összes lehetséges 
forrástól egy adott célhoz tartó utak fát alkotnak, amelynek 
gyökere maga a cél. (A fa olyan gráf, amelyben nincs kör). 
Ezt a fát nyelőfának (sink tree) nevezzük. (3. ábra). 
Észrevehető, hogy a nyelőfa nem feltétlenül egyedi, 

azaz nem csak egy optimális útvonal létezhet például 

az A router és a többi router között. A forgalomirányító 
algoritmusok feladata valójában pont az, hogy ezekre az 
utakra rábukkanjon. 

A fák tulajdonságából következik az is, hogy minden cso- 
mag véges (korlátos számú) ugráson belül eléri célját. 
(Ugrás alatt most egy routeren történő keresztülhaladást 
értjük). Ez azonban csak a mi példánkban van így, a gya- 
korlatban minden bizonnyal nem áll fent. A routerek 
ugyanis elromolhatnak és hirtelen megjavulhatnak, így 
nem biztos, hogy például minden router ugyanúgy ,képze- 
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hogy az egyes routerek miként tudják beszerezni azokat az 
információkat, amellyel a nyelőfát felépíthetik. Erről a kö- 
vetkező részben szólunk részletesen, amikor a gyakorlatban 
is használt forgalomirányító algoritmusokkal ismerkedünk. 
Ugyan az optimalitási elvnek és a nyelőfának közvetlen 
gyakorlati haszna nincs, mégis egyfajta viszonyítási alap- 
ként szolgálnak a való élet forgalomirányító algoritmusai- 
nak összevetése során. 


Garzó András 
garzo(Vinterware.hu 
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Főzzunk Linuxszal: Elfelejtett biztonság 


Jobb ha nem használjuk ugyanazt a jelszót több azonosítóhoz. Tekintve, hogy 
mennyi jelszóigényes kiszolgáló és weblap létezik, mit tehet ilyenkor egy bizton- 
ság-tudatos főszakács? Nézzük meg, hogyan tehetjük kényelmessé és biztonsá- 


gossá a jelszó pásztorkodást. 


ol van az a borrendelés Henri Különleges Boraitól, 
Francois? Úgy tűnik kezdünk kifogyni a kedven- 
ceimből. Henri általában otthon van ezen a téren. 
Nem adott neked visszaigazolást? Ah, kitűnő. Akkor meg- 
van a rendelés? Nem? Hogy érted, hogy valahol bizton- 
ságban van? Most akkor meg van, vagy nincs? Értem. 
Úgy gondoltad, hogy fontos, ezért titkosítottad a rendelést 
és eldobtad az eredeti üzenetet. Had találjam ki, mon 
ami, nem emlékszel a jelszóra amivel titkosítottad az üze- 
netet. Ahogy gondoltam. Rendben, mutasd milyen prog- 
ramot használtál. 

Steganográfia, Francois? Saját arcképedbe rejtetted a bor- 
rendelést? Le vagyok nyűgözve! Ezzel a problémával egy 
kicsit később foglalkozunk, Francois. Nincs túl sok időnk, 
vendégeink bármelyik pillanatban itt lehetnek. Ah, de hát 
már itt is vannak. 

Üdvözlet, mes amis Chez Marcelnél, a világ legfinomabb 
francia Linux éttermében és a világ legnagyszerűbb boros- 
pincéjében. Amely sajnos jelenleg lehet, hogy csak a má- 
sodik legjobb a világon. Úgy tűnik hűséges pincérem elka- 
varta a rendelést és nem akarta elmondani nekem. Igen, 
Francois, tudom, hogy tudod hol van. Menj a pincébe és 
hozd fel a portugáliai 2000-es Douro-t. Kiváló vörös, mes 
amis, testes és erős bor, gyönyörű sötét gyümölcsillattal 

és egy csepp misztikummal. Vite, Francois! 

Míg Francois felhozza a bort, elmondom hogyan próbálta 
meg biztos helyre tenni a borrendelést. Mint kiderült, 
Stefan Hetzl Steghide nevű programját használta, hogy 

a listát saját tényképébe rejtse (1. ábra). 

Ezt a módszert szteganográfiának nevezik. A módszerrel 
tetszőleges üzenetet rejthetünk egy másik üzenetbe (vagy 
mint ebben az esetben egy grafikus képbe). Iulajdonkép- 
pen, egy titkos üzenetekkel megtűzdelt képekkel teli 
weblapot is létrehozhatunk, és senki nem fog sejteni sem- 
mit. A Steghide-ot a Steghide honlapjáról gyűjthetjük be 
(lásd a hálózati forrásokat). A kiadott futtatható állományo- 
kat könnyen meg fogjuk találni. Ha a Steghide-ot forrásból 
szeretnénk fordítani, szükségünk lesz a libmhash, libjpeg, 
zlib és libmcrypt fejlesztői könyvtárakra. Ezek után már 
könnyű dolgunk van, a szokásos öt lépéses kitömörítés 

és fordítás menettel találkozunk: 
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1. ábra Ebbe a képbe rejtve valahol egy jókora borrendelést találunk 


tar -xzvf steghide-0.5.1.tar.gz 
cd steghide-0.5.1 

. /configure 

make 

su -c "make install" 


A borrendelés elrejtése esetében Francois a következő 
parancsot használta a dokumentum képbe ágyazásához: 


steghide embed -cf francois.jpg -ef wine order.txt 


műagnecírancois s almat com mmtbigdriversoítwarejs ecurity/oms:0.94- Shell No: 2 -Konsole 225 


Man men vű 


2. ábra PMS nem csak jelszavakhoz használható. 
Akár a szekrénykódunkat is tárolhatjuk benne. 


Ha már borról beszélünk, Francois visszatért. Légy oly ked- 
ves, mon ami, és tölts a vendégeinknek. Nos, a parancs fut- 
tatása után egy jelszót kell megadnunk: 


Enter passphrase: 

Re-Enter passphrase: 

embedding "wine order.txt" in "francois.jpg" . . . 

5 done 

Eredményképpen a titkos üzenet elrejtését megelőző válto- 
zattal azonos kinézetű képet kapunk, de a mérete megvál- 
tozik. Ha az adatokat ki akarjuk nyerni a képből, nekünk 
(vagy akinek a képet elküldtük) csak az extract paramétert 
kell megadnunk a következő paranccsal: 


steghide extract -sf francois.jpg 
Enter passphrase: 


Amennyiben sikeresen megadtuk a helyes adatokat, a rej- 
tett állomány a lemezre kerül. Nos, éppen ez az a pont ahol 
a dolgok elkezdenek rosszra fordulni. Miután elfelejtettük 
a jelszót, nincs többé módszer az információ kinyerésére. 

A valós életben néhányan közülünk alkalmanként elveszít- 
jük a kulcsunkat. Mások rendszeresen elvesztik, aminek kö- 
vetkezményeként egy vállalati feltaláló kijött a kulcscsomó- 
ra szerelhető csipogóval. Feltételezve, hogy a keresőt már 
nem veszítjük el, csak megnyomjuk a gombot és a kulcs 
magas hangon csipogva jelzi melyik díszpárna mögé csú- 
szott be éppen. 

A jelszavak esetében hasonló az alapötlet. A legegyszerűbb 
módszer leírni a jelszavakat valahová vagy egy szöveges 
állományba menteni őket. Ez azonban nem különösebben 
biztonságos. Ugyanakkor a jelszó és jelszöveg lista készítése 
egyre nagyobb értelmet nyer, ahogy jelszavak tucatjait, 
néha százait kell megjegyeznünk. Mennyivel egyszerűbb 
lenne, ha csak egyetlen jelszót kéne megjegyeznünk! 

Itt kerülnek a képbe a jelszókezelők. 

Az első ilyen amibe belefutottam Dennis Pries Password 
Management System (azaz PMS) rendszere volt. Ez azért 
tetszett, mert tisztán szöveges terminálablakban is futtatni 
lehetett, következésképpen bárhol legyünk is, egy héjbeje- 
lentkezésből használni tudjuk. A programot a SourceForge 
honlapján találhatjuk meg (lásd a forrásokat), ahol a forrást 
és a Debian csomagot egyaránt letölthetjük. 
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A PMS fordításához dupla kitömötítés és az öt lépéses 
fordítás szükséges. Először is csomagoljuk ki a tarolt és 
gzippelt állományt (tar -xzvf pms-0O. 94. tar . gz7). Bele- 
kukkantva a forráskönyvtárba egy contrib alkönyvtárat lát- 
hatunk, ahol a forrásfájlból a kicsomagolás és fordítás szo- 
kásos öt lépésével elkészíthetjük a cdk-t. A cdk telepítése 
után lépjünk vissza a PMS forráskönyvtárába, fordítsuk 

le és telepítsük. 

A jelszókezelőt a pms paranccsal indíthatjuk. Első indításkor 
meg kell adnunk a mesterjelszót. Ez az egyetlen jelszó vagy 
jelszöveg, amit mostantól meg kell jegyeznünk, ezt viszont 
alaposan. Ha elfelejtjük a mesterkulcsot soha nem látjuk vi- 
szont a többi jelszavunkat. A PMS egyszerű menüjével gép- 
neveket vehetünk fel, törölhetünk és nevezhetünk át. Ezek 
lesznek azok a helyek, ahová be kell jelentkeznünk. Először 
is vegyünk fel egy gépnevet (például, www.somewhere.dom) 
majd fűzzünk megjegyzést hozzá (például: központi rend- 
szer). Ezután ismét a főmenüben találjuk magunkat. Ítt vá- 
lasszuk a User Hunctions (Felhasználói Műveletek) pontot. 
Ebben a menüpontban vehetjük fel vagy törölhetjük az elő- 
ző lépésben megadott géphez tartozó felhasználói azonosí- 
tókat. Egyúttal itt jeleníthetjük meg a felhasználóhoz tartozó 
elveszettnek hitt jelszavainkat is. 

Mielőtt továbblépnénk, szeretnék rámutatni, hogy a gépnév 
és a felhasználói név akármi lehet. Gépnévként beírhatom 
azt is, hogy , iskolai zár", felhasználónévnek, hogy ,kombi- 
náció" jelszónak pedig magát a kombinációt. Bár eredetileg 
bejelentkezési információk őrzésére tervezték, a program 
más célra is jól használható (2. ábra). 

A másik dolog amit mindig el szoktunk felejteni, a rengeteg 
meglátogatott weblaphoz rendelt jelszavak. Az on-line ban- 
ki rendszerektől kezdve a hírújságokig ahol ingyenes azo- 
nosítóra van szükségünk a cikkek olvasásához, idővel irgal- 
matlan sok jelszó gyűlik össze. Aztán ott vannak az üzenet- 
küldőkhöz és az e-mail bejegyzésekhez tartozó jelszavaink, 
az FIP helyek és még hosszan sorolhatnánk. Jelentősen 
leegyszerűsítené a dolgunkat, ha mindezt az információt 
valahogy átlátszóan tudnánk kezelni munka közben. 

Van esetleg valamilyen eszköz ami beépül az asztalba? 

A válasz természetesen igen. A KDE 3.2, és a legújabb 

3.3 verziójában a felhasználók beépített a jelszókezelővel 
rendelkeznek. George Staikos KDE Wallet Manager rendsze- 
réről van szó, amely a kwal letmanager programot futtatja. 
A program első indításakor nem készül tárca (wallet). 
Ugyanakkor a rendszertálcán egy apró tárca ikont találunk. 
Amennyiben a tárcakezelő ikonja még nincs nyitva, kattint- 
sunk az ikonra, mire megnyílik egy (leginkább üres könyv- 
tárra emlékeztető) üres doboz. Kattintsunk a Beállítások 
(Settings) gombra a menüben és válasszuk a Tárcabeállítások 
(Configure Wallet) pontot. 

Új űrlapablak jelenik meg, ahol a legtöbb elem nem elérhe- 
tő. Kattintsunk a KDE tárca alrendszer engedélyezése (Enable 
the KDE Wallet Subsystem) pontra. Most már néhány 
további lehetőséget is elérhetünk (3. ábra). 

Figyeljük meg az Automatikus Tárcaválasztás (Automatic 
Wallet Selection) nevű középső részt. Meg kell adnunk 
melyik tárcát szeretnénk alapértelmezettként használni. 
Rögtön ez alatt kiválaszthatjuk a helyi jelszavakhoz hasz- 
nált tárcát (erről hamarosan még bővebben szó lesz). 

Ha először futtatjuk a KDE Tárcát, nem valószínű, hogy 
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Configure - KDE Wallet 


Wallet Preferences I Access Control; 


X Enable the KDE wallet subsystem 
- Close Wallet- 
! ! Close when unused for. 








. ! Close when screensawver starts 


. ! Close when last application stops using it 





- Automatic Wallet Selection 
Select wallet to use as default 








. ! Different wallet for local passwords: 











-Wallet Manager 
XX. Show manager in system tray 





XX Hide system tray icon when last wallet coses 














— Help )! Defaultsó ) (OK )/ Apply !) Cancel / 





3. ábra A KDE Tárcakezelő beállítása jelszótároláshoz 


van létező tárcánk; Kattintsunk az Új (New) gombra és 
adjunk nevet a tárcánknak. Nyugodtan adhatjuk a saját 
nevünket ahogy én is tettem. Miután begépeltük a nevet 

és ráböktünk az OK-ra, a megjelenő KDE tárcakezelő 
varázsló (KDE Wallet Manager Wizard) alap vagy kifino- 
mult beállítási lehetőségei közül választhatunk, ahol az alap 
a javasolt mód. A kifinomult változatban kicsit több infor- 
mációs képernyőt találunk és a helyi jelszavainkhoz külön 
tárcát választhatunk. Én az alapot választottam és csak egy 
tárcát készítettem. 

Bármelyiket is választottuk a varázsló egy idő után rákér- 
dez a tárca megnyitásához szükséges mesterjelszóra. 

Ez a szuperfelhasználó jelszó lesz az amit nem szeretnénk 
elfelejteni- az, amely az összes többi ajtaját nyitja. Jól vá- 
lasszunk, és ne felejtsük el az , Igen, személyes adataimat 

is szeretném a KDE tárcában tartani" (,,Yes, I wish to use the 
KDE wallet to store my personal information") négyzetet 
megjelölni. 

Ha a varázslóval végeztünk, majdnem készen is vagyunk. 

A felbukkanó üzenetablak tudatja velünk, hogy az alkalma- 
zás (a varázsló) szeretné létrehozni az új tárcát. A kérelmet 
a tárcához tartozó jelszóval kell jóváhagynunk. Figyeljük 
meg ezt az űrlapot. Ehhez hasonlót fogunk látni minden 
KDE folyamatban amikor valamelyik alkalmazás jelszót ke- 
resve meg szeretné nyitni a tárcát. Amíg ki nem jelentke- 
zünk, a tárca nyitva marad. Lépjünk be egy weblapra ahol 
jelszót és felhasználónevet kérnek tőlünk (például megnyit- 
hatjuk a banki elérésünket). Miután kitöltöttük az informáci- 
ókat és ráböktünk az Elküld vagy Enter gombra (űrlaptól 
függően), a KDE tárcakezelő ablaka jelenik meg figyelmez- 
tetve, hogy egy alkalmazás (jelen esetben a Kongueror) meg- 
próbálta megnyitni az alapértelmezett tárcát (amit éppen 
most készítettünk). A 4. ábrán láthatjuk mire gondoltam. 
Írjuk be a mesterjelszót és bökjünk a Folytatásra (Continue). 
Egy utolsó figyelmeztetést kapunk, miszerint a titkosított 
adatok elmentésre kerülnek, és ezt jóvá kell hagynunk. 
Kattintsunk az Igen gombra. Most vessünk egy pillantást 

a tálcára és látni fogjuk, hogy az ikon zárt tárcáról kissé 
nyitott tárcára változott. 
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LELTEK 


KENVAllet service - KE [ddeiTon 


The application kongueror has reguested to 
apen the wallet MarceT. Please enter the 
pássword for this wallet below. 


L.Open JI Cancet ) 


4. ábra A tárca megnyitásához meg kell adnunk a mesterjelszót 


E rendszer szépsége, hogy az adatok automatikusan be- 
íródnak nekünk amikor legközelebb meglátogatjuk a lapot. 
Ez minden KDE alkalmazásra igaz, amely jelszót kér tő- 
lünk, tehát például az üzenetküldőre is. 

Egyetlen buktató van, mégpedig nem is kicsi. Mint em- 
lítettem, csak egyetlen egyszer kell begépelnünk a mes- 
terjelszót minden KDE folyamathoz, ami leegyszerűsíti 

a dolgokat. De vigyázat: most, hogy a rendszert képes- 
sé tettük a jelszavaink automatikus megadására, az asz- 
talunk biztosítása igencsak fontossá válik. Ne feledjük 

el lezárni az asztalt mielőtt elmegyünk. Másik megol- 
dás, hogy visszalépünk a KDE tárca beállítások űrlap- 
jára és megismerkedünk a Tárcazárás (Close Wallet) 
lehetőségeivel. Beállíthatjuk, hogy egy megadott idő után 
automatikusan záruljon be, például, amikor a képernyő 
pihentető elindul (azaz amikor általában nem vagyunk 
ott) vagy amikor a tárcát használó utolsó alkalmazás 

is becsukódik. Ha így járunk el, egyel kevesebb dologra 
kell emlékeznünk. 

A faliórára pillantva, mes amis, úgy látszik ismét utol- 
ért bennünket a záróra. Mint láthattuk több lehetősé- 
günk is van jelszavaink tárolására így nem kell tucatnyi 
titokzatos betű és számkombinációt megjegyeznünk. 
lalán, ha sikerül meggyőzni Francois-t, hogy ilyen eszkö- 
zöket használjon a jövőben, nem lesz több eltűnt rende- 
lés. Addig is, abban biztos vagyok, hogy sikerül meggyőz- 
ni, hogy még egyszer töltse teli vendégeink poharát. 

És a bortartalékok miatt ne aggódjon senki. Személyesen 
gondoskodom róla, hogy a borospince színültig legyen 
mire legközelebb találkozunk. Addig is, mes amis, egész- 
ségünkre. A votre santé! Bon appétit! 
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A cikkehez tartozó források: 
2 www.linuxjournal.comjarticle/7860 


Marcel Gagné (mggagnesalmar.com) 
Mississaugaban él Ontario államban. Ő a szer- 
zője a Moving to the Linux Business Desktop 
(ISBN 0-131-42192-1) című könyvnek amely 

a harmadik műve az Addison-Wesley gondozá- 
sában. A valós életben a rendszerintegrációval 
és hálózati tanácsadással foglalkozó Salmar 
Consulting, Inc. elnöke. Egyúttal pilóta, sci-fi 
és fantasy novellákat ír és silány origami [-Rex 
figurákat hajtogat. 


Munka- és szolgálati viszony I. - Általános rész 


A szoftverekkel kapcsolatos, már részleteiben érintett probléma a munkaviszony- 


ban alkotott szoftverek esete. 


tt telmerülnek olyan kérdések, hogy mi minősül egyálta- 

lán munkaviszonyban alkotott műnek? Mennyire tág 

a munkaszerződés hatásköre, milyen — a megítélést befo- 
lyásoló -— szerepe lehet a program megalkotásához szükséges 
infrastruktúra rendelkezésre bocsátásának, van-e eltérés a kö- 
tött munkaidejű programozók alkotásai között illetve azok 
esetében, akik csak meghatározott óraszámot kötelesek ledol- 
gozni, ám tetszőleges időpontokban (saját választása szerint 
akár hétvégén, vagy éjszakákba nyúlóan)? A szerzői jogi tör- 
vények általában véve munkaviszonyban alkotottnak minősí- 
tik azokat a műveket (így a szoftvereket is), melyek elkészítő- 
je és később vagyoni jogi jogosultja közötti, a munkavégzést 
rendező viszonyt a Munka törvénykönyve, a Közalkalmazotti 
illetve a Köztisztviselői törvény rögzíti. Ám az ezekhez pusz- 
tán hasonlító szerződési formák esetében nem állapítható 
meg munkaviszony léte, s így a művekre vonatkozó vagyoni 
jogosultságok automatikus átszállása sem. Ennek oka a szer- 
zői jogi törvény szerzővédő értelmezési elve lehet. 
Érdekes kérdést vet fel, ha a szoftver egy érvénytelen 
munkaszerződés keretei közt jön létre, itt a körülmények 
elbírálása lesz a döntő arra vonatkozóan, hogy a felhasz- 
nálási jogok, legalább a jogügylet licenc szerződésnek való 
minősítéséből kiindulva átszálltak-e. 
Ha kétség merül fel, a munkáltató köteles bizonyítani, hogy 
a program megalkotása munkaviszonyból fakadó kötele- 
zettség volt, amennyiben erre nem képes, a szerző szaba- 
don rendelkezhet művével. 
Külön kérdéskört jelent az igénybe vett hardver esete. 
Míg a nyolcvanas évek elején elképzelhetetlennek tűnt 
a szoftveralkotás otthoni körülmények között, és feltétlenül 
nagy beruházást igényeltek az olyan számítógépek, melyek 
egy komolyabb program futtatására alkalmasak voltak, 
mára már lényegesen egyszerűbbé vált a megfelelő hard- 
verháttér biztosítása, ám ugyanakkor előfordulhat, hogy 
a munkavállaló a munkájához kapcsolódó, ám nem munka- 
köri feladatai közé tartozó módon, munkahelyén kívül, sa- 
ját hardveren a munkáltatója számára is hasznos szoftvert 
fejleszt. Amennyiben ez a szoftver összefügg a munkahe- 
lyén megismert know-how ismeretekkel, kötelessége lesz 
a munkáltató számára felkínálni a művet, míg az otthoná- 
ban alkotott szoftverek esetében alapvetően az a feltéte- 
lezés él, hogy a munkaviszonyon kívül alkotott a mű. 
Ugyanakkor a szoftverfejlesztés tipikusan az a terület, 
ahol a ,távmunka" minden gond nélkül megvalósítható. 
Sajátos megoldást jelentene, ha a szabadalmi alkotások 
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mintájára, elhatárolást nyerne a , szolgálati" illetve az 

, alkalmazotti találmányhoz" hasonlóan a , szolgálati" illetve 
, alkalmazotti mű" megkülönböztetése a szerzői jogban. 
Ezen felosztás szerint a munkaköri kötelességként alkotott 
szoftver esetében a munkáltató a vagyoni jogok megszer- 
zésére, míg munkaviszonyból eredő kötelezettségen kívül 
fejlesztett szoftverekre, amennyiben annak hasznosítása 

a munkáltató tevékenységi körébe tartozik, csak felhaszná- 
lási jogot nyerne a munkáltató. 

Ugyancsak megfontolandó szoftverkészítők esetében 

a munkaidő fogalma, hiszen a hely meghatározásán túl az 
idő is fontos tényező. A munkaidőn túli teljesítményért az 
általános szabályok szerint túlóradíj illetné meg, amennyi- 
ben azonban ezt nem utalják számára, feltételezhető-e, 
hogy a műért cserében megfelelő ellenszolgáltatást kapott? 
Fontos figyelembe venni azt, hogy a munkáltató nem sajá- 
títhatja ki a programozót, így annak is joga van — még ab- 
ban az esetben is, ha ő az egyetlen, az adott témához értő 
szakember egy cégnél - a szabadsághoz, és ahhoz, hogy 

a szabad idejét saját elképzelései szerint töltse el. 

A legszigorúbb elhatárolást mégis a munkaköri leírás je- 
lenti, hiszen általában ez alapján ítélik meg a szoftver elké- 
szítésénél releváns körülményeket. Ugyancsak munkavi- 
szonyban alkotottnak minősül a mű, ha az elkészítésére 

a szerző utasítást kap, ám ilyenkor kérdéses, hogy az utasí- 
tás mennyiben terjeszkedhet túl az adott a munkakörön, hi- 
szen például egy éjjeli őr is lehet jó programozó, de ez még 
nem jelenti, hogy a munkáltató őt egy szoftver elkészítésére 
utasíthatja. Ehhez kapcsolódó a német bíróság egy 1997-ből 
származó döntése, ahol a bíróság kimondta, hogy a techni- 
ka fejlődéséből következik, hogy egyszer elérünk majd egy 
pontot, mikor egy felelősségteljes munkakört betöltő sze- 
mélytől elvárható lesz nem csak a programok futtatásának, 
hanem fejlesztésének képessége is, és attól kezdve a szoft- 
veralkotás a munkaszerződések részét fogja képezni. 

Ám már ezen állapotot megelőzően is megállapítható, hogy 
amennyiben a munkáltató jóváhagyásával és annak költsé- 
gére a munkavállaló szoftvert fejleszt, az a munkaszerződé- 
si tevékenységi kör keretein belülinek minősül. 

Az egyes jogokra speciálisan hat, amennyiben munkavi- 
szonnyal összefüggően gyakorolják őket, bár nagy részüket 
már említettük, érdemesek még egy összefoglaló áttekintésre. 
Erre azonban a következő hónapban térünk ki részletesen. 
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